The biggest challenge that was faced in web based applications was building of interactive websites.
This post tries to summarize how Microsoft tried to solve this challenge with various technologies, the problems that arised in each of these and how these problems were solved by their successor. (Reference : ASP.Net MVC in Action, 2nd Edition)
CGI (Comman Gateway Interface)
The first solution to this challenge was to build websites using executable programs that ran on a server. The programs (also called as scripts) accepted a web request and were responsible for creating an HTML response.
The technologies used initially to write these programs (scripts) were CGI (Comman Gateway Interface).
Drawbacks of CGI
- Adhoc Templating.
- Programs were difficult to write, debug and test.
ASP (Active Server Pages)
In late 1990s, Microsoft introduced Active Server Pages (ASP).
ASP ran on the concept of having server pages (pages that got executed on server side) , which was nothing but an HTML document that was embedded with dynamic scripts (code that got executed at runtime) . So an ASP page was a mixture of (or made up of) HTML markups and scripts where the HTML markups were used to handle the User interface (or presentation of the page) and scripts were used to handle the the action (program logic) of the page.
- ASP brought templating to web applications. (not clear what templating is.)
- As the executable script had to be embedded \ mixed in with the HTML document, the world soon saw massive server pages with code indecipherable (inseparable \ unidentifiable) from the HTML markups.
In early 2002, Microsoft launched ASP.Net and the Web Forms Framework.
Web Forms was a huge shift as it moved most of the program logic, which was previously embedded between HTML markups, into a class file ( called as code behind ) and replaced the HTML markups with something called as dynamic server controls, which were written in an XML syntax.
Hence in ASP.Net the following changes were made :
- XML based dynamic server controls instead of HTML markups.
- Program logic was to be written in class files called as code behind, instead of embedding them between markups.
- Performance of web applications increased.
- Debugging experience improved.
- ASP.Net introduced the concept of postback event lifecycle , which saw heavy query mails on newgroups, as confused developers searched for that magic event in which to add those two simple lines of code that was necessary to make the page work as needed.
- The concept of ViewState, which although good in theory, broke down as the application scaled with complexity.
- Simple pages surpassed 100kb in size, as the entire state of the application had to be stored in the output of every generated page.
- Development best practices were ignored as tools like Visual Studio encouraged data access concerns (data access activities) such as SQL queries to be embedded within view logic.
- The biggest sin of Web Forms Framework was the tight coupling to everything in the System.Web namespace.
- There was no scope of unit testing any code in code-behind file, due to the way the flow of ASP.Net pages was designed (eg .. any task that was to be automatically performed in the page had to be written in the Page_Load event) and due to this we saw Page_Load methods that took several trees to print.
- Seperation of Concerns Using MVC Architecture
- The ASP.Net MVC works on the concept of seperation of concerns (i.e seperation of responsibilities).
- This is done by providing support for development of ASP.Net applications using Model – View – Presenter (MVP) web presentation pattern.
- With this the concerns of the data model, the application logic and data presentation are clearly separated. The application logic is kept in a class which is seperated from the hard dependencies on how the data will be presented. Server pages have become simple views, which are nothing more than HTML templates waiting to be populated with objects(models) passed in by the controller.