Microsoft first released ASP.NET almost eight years ago. At that time, they created a model they hoped would be familiar (and compelling) to Windows forms developers, particularly to those working in Visual Basic 6.

ASP.NET adopted a development paradigm that mimicked Windows forms. This programming model was referred to as “web forms” and it abstracted away much of the complexity of HTML and HTTP, easing the transition from Windows to the web for many developers. Using web forms, developers could drag controls, such as buttons and textboxes, onto a design surface and add code that ran automatically when a user interacted with a control – such as when a user clicks a button. Pages and controls had events, such as Load and Init that ran at specified times during a page’s creation. By default, each page had a code-behind file – class containing code that responded to page events. These concepts were familiar to Visual Basic developers and this helped to drive adoption of ASP.NET.

But there are some drawbacks to this model. Web forms abstracted away the details of HTML and HTTP, but this abstraction cost the developer control over the rendering of pages and controls. Some developers felt that the web forms framework got in the way of their web developing by hiding these basic constructs. Also, tying code to web form events made it difficult to test much of the application. Testing frameworks evolved that would mimic the behavior of a web server, just to integrate with automated unit testing frameworks.

Recently Microsoft released ASP.NET MVC - a new programming framework designed to build web applications with HTML and HTTP. This framework uses the Model-View-Controller pattern.

The Model-View-Controller pattern is not new. However the release of ASP.NET MVC (I’ll refer to it as "MVC" going forward) has renewed interest in this pattern.

MVC consists of three main parts. You’ll never guess what they are. Give up? They are the Model, the View and the Controller.

The Model contains the application’s data and any business rules associated with that data. It is up to the Model to retrieve and update data from and to a database (or other persistent data store or back-end), to validate that data and to apply any business rules to that data.

The View is a template for the user interface. It should contain no logic at all. In fact, in the ASP.NET MVC framework, by default View web pages don’t even have a code-behind file. A view in this framework consists only of HTML mixed with some placeholders to output values from the model or helper functions based on those values.

The Controller is the glue that binds the Model to the View. By default, each web request in ASP.NET MVC gets routed to a given method (known as an “Action”) of a given class (known as a "Controller"). This method executes and returns either a view or enough information for the framework to identify and render a view.

MVC has two main advantages over web forms –It is easier to test and it gives more control to the developer.

Separating an application into three distinct parts makes it far easier to test.  Launching a user interface in an automated testing framework, such as NUnit or MSTest is possible but it’s clumsy and slow. Minimizing the code in the user interface allows us to test the code more easily.

MVC also gives the developer more control over the rendered HTML (the view) than is possible in web forms. Web forms deliberately abstract away much of the HTML rendering, while MVC forces the developer to write explicit HTML in his View templates.

The release of ASP.NET MVC certainly does not signal the end of web forms.  Many developers appreciate the abstraction that web forms provides for them. Many web forms still exist in production and I have yet to hear anyone refer to these as "legacy" applications or "Classic ASP.NET".

But for those who want more control over their output, a more pure separation of concerns and easier testability, ASP.NET MVC offers a good option.