ASP.NET MVC and Web Forms — Shaping the Future of the Web

Share on TwitterShare on TumblrSubmit to StumbleUponSave on DeliciousDigg This
Ever since the release of ASP.NET MVC there is a constant buzz to evaluate its features and compare it with traditional Web Forms development. This article compares both these frameworks to help the developer community decide the use of appropriate framework while working on actual projects.


ASP.NET Web Forms development is a rich and matured technology for web development on the Microsoft platform. It allows quick development, rich user interface and rapid adaptability by naïve developers. Developers get WYSIWYG kind of designer support right in the development environment. But this ease of usage brings certain issues from maintainability, testability and performance-related point of views. Due to new expectations from web applications and better control over the content, Microsoft’s focus has changed a little bit, and now we have an alternative.

ASP.NET MVC is a new programming paradigm in web application development and is as revolutionary as ASP.NET itself was a decade ago. The first version of the MVC 1.0 was released in March 2009 where it was a separate installer. Microsoft is so backing on to MVC as the next big thing in the web development arena that they have not only made MVC 2 part of .NET framework 4.0, but also made it open source, http://aspnet.codeplex.com/releases/view/41742, like the AJAX toolkit. So you can download the MVC source code and suggest improvements and at the same time have custom implementation, since you have the power of entire source code. The latest preview of MVC 3 is available @ http://aspnet.codeplex.com/releases/view/50092

Before it gets too complicated for an Introduction part, let’s get on with understanding more about ASP.NET MVC.

Diagram 1: Parallel existence of Web Forms and MVC.

What is ASP.NET MVC?

MVC stands for Model, View, Controller, is a design pattern used for software development that supports separation of business logic from the user interface and application input. There is nothing new in this pattern that Microsoft has re-invented. The design pattern was there since long back and pretty much used in web arena also, but as stated earlier, Microsoft’s focus has changed recently and is a new addition to ASP.NET.

  Diagram 2: ASP.NET MVC Components. 


The Controller is the one that receives the input and initiates Model to reflect the correct state of the application. For example, the Controller handles the user interaction request and selects appropriate action handler to execute and passes the query string values to the Model, which in turn can query database based on information received from Controller.


View is the MVC component that displays the application’s user interface (UI). Usually, Model data is used to render the UI. Example would be an editable view of a Products table that displays text boxes, drop down lists, and check boxes based on the current state of a Product object. View renders any change in the UI. View does not contain any business logic and receives information from Controller.


Model represents the state aspect of the application and passes the information back to Controller. Model generally interacts with database, web services and NHibernate etc. Controller sends the Model information to View. In small to medium applications, the Model is often a theoretical separation instead of an actual one. For example, if the application only reads a dataset and sends it to the View, the application does not have a physical Model layer and associated classes. In that case, the dataset takes on the role of a Model object. Hence it’s an optional component in MVC.

ASP.NET MVC is a web variation of the standard MVC design pattern and in this there is no direct link between the model and the View. This is done in order to have clear separation between Model and View.

MVC or Web Forms?

Since MVC is just an alternate to Web Forms development and not a replacement, there always remain a big question that when should we go for MVC and when should we stick to Web Forms.

MVC scores over Web Forms in most of the areas, especially when it comes to out of the box options. Features that require explicit effort in Web Forms are available right from the ground up in MVC. Next sections discuss all these points in detail.

Separation of Concerns

MVC assigns clear responsibility to all the 3 involved components. While Controller handles the HTTP request, Model holds the business logic, data access layer. View ensures data validation and display the application’s user interface (UI). As per this architecture, Controller will never try to access database directly or for that matter View will not hold any business logic in it. This is different from a Web Form where controller and view are just about combined and gives fake sense that code behind is separated from the view, whereas in reality they are tightly coupled and requires explicit extra efforts to introduce separations.

Separation of concern can lead to significant productivity improvement since this lets you implement the code in parallel. While one of the team is working on Data Model design and implementation, we can have Views and Controllers developed in parallel. This separation also results into better code maintenance, extensibility and adaptability.

Separation of concerns also lets you implement DRY principle (Don’t Repeat Yourself). DRY idea is to code it once and that’s all. A DRY design removes the code redundancy, which makes projects faster to compile and easier to maintain. For example, validations using Data Annotations can be implemented within Model which ensures that no matter where you use the Model; all validations will still be enforced. Generally, Create and Edit pages use the same kind of View layout. MVC provides the flexibility to define “partial view” that can be used to encapsulate view rendering logic for a sub-portion of a page. This provides a powerful way to define logic once, and then re-use at multiple locations.

Conventions over Configuration

The thought is pretty simple, stick to the conventions and avoid too much configurations. We all know how big those web.config files get when we do standard ASP.NET Web Form application development. Also, we always need to mention specific details of the method while calling. However, in MVC if we follow certain naming conventions for classes, files and folders we can avoid many of the configurations and explicit settings. For example:

 Diagram 3: Conventions over Configuration.

Simple statements like return View(); can automatically reference the Index.aspx view in the Home (name of the Controller) folder under the Views folder. This avoids specifying the view name explicitly and keeps the code simpler and cleaner. There are various other places where conventions can really ease the job during development and helps improve the productivity. For example, you can create a View straight from the Controller by right-clicking and Visual Studio will prompt about the type of View you would want to create and framework will accelerate in creating a View pretty fast for you.