About C&K Online v5

C&K Online has gone through several iterations since 2005 when it was first launched.

Version 1 was a dirty PHP site. The code was messy and there were no class definitions. In fairness, PHP wasn't as evolved back then, but the code could have been made more modular than it was. Every page had to perform database access, business logic, and display the results. Usually all inline within the page requested. This design made it hard to find and fix bugs, in addition it made it hard to add new features. In addition, authentication and authorization was contained within the application, which meant that every user had to be configured, possibly with a different password from what they know.
Version 2 was an ASP.Net 2.0 web application. ASP.Net was an improvement over the dirty PHP site, but not by as much as I would have liked. The code was slightly more modular and various sub-applications could share common functionality. However, like the PHP version, every page was a monolithic mess of data access, business logic, and display code. ASP.Net did introduce data sources that helped to consolidate data access code, but there was still a large amount of data access code built into every page. In addition, ASP.Net tried to maintain an application state between requests which causes excessive data to be transferred from the server to the client and back. This increased traffic slowed down the application. Authentication and authorization was still contained within the application.
Version 3 was a modular approach to an ASP.Net 2.0 web application. Each web application ran separately from every other web application, but they still shared common functionality. This was not efficient for storage since every app had a copy of the common libraries, but it made it easier to design each app independent of every other app. This was the first version designed to allow each app to use a different database. Authentication was moved to a central service that allowed all apps to share credentials and user settings. The central service allowed users to be authenticated against Active Directory, allowing for a single password common across all services. Unfortunately, this version still suffered from the ASP.Net issues of being relatively monolithic in a code sense.
Version 4 was a leap in capabilities and the first version to use an model-view-controller architecture by using the ASP.Net MVC framework. This architecture clearly separates the data access, business logic, and display code. The inclusion of the Entity framework also allowed for code-first data access. That means that the objects designed in code created the database, not the other way around. However, when designing version 4, I decided to go back to the single application design. Since the frameworks consisted of many megabytes of libraries, this move saved a lot of space. It also made it possible to guarantee that each sub-app had access to the latest functionality. Unfortunately, this design was a bad idea. It meant that every time a core function was updated, all sub-apps had to be recompiled and manually tested to verify nothing was broken. This version allowed for mixed authentication, both built-in and against Active Directory. While this version did not enforce a single database, it did tend to nudge for it, since in order to separate the databases of sub-apps it would mean loss of continuity for user management.
Version 5 (this version) is a mixture of version 3 & 4, but using an entirely different technology. Version 5 makes use of Ruby on Rails, which is a model-view-controller architecture using the Ruby programming language. Ruby is a fairly easy to read language, which means anybody should be able to follow along with a little bit of knowledge, and it is an interpreted language (like PHP) which means that changes can be made immediately (unlink ASP.Net and ASP.Net MVC). Rails has a powerful ORM system which makes designing and working with database tables easy, and the Ruby language and Rails both take a convention over configuration approach, which means that if you follow the conventions, you need relatively little code to accomplish a task. Version 5 is taking the modular approach so that separate apps do not necessarily need to share a single database or even a common codebase. Version 5 is a base to build other applications on top of, and can be thought of as a replacement for Access Databases.