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.

Introduction

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

[login]

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. 

Controller

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

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

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.

Test Driven Development (TDD)

MVC is best suited for test driven development and well-matched where testing is a prime concern. This is where developer can write test cases ahead of the actual code and then run the test cases to verify the accuracy of the code written. The crux of the difference between Web Forms and MVC exists in this area. Web Forms development makes it very difficult to write automation test scripts because of the underline associated events. You need to browse through the application pages and generate all those events that require testing. However, in MVC we write Controller methods for every possible (GET/POST) request applicable in the application and that can be tested without browsing through the entire application manually. So even though the testing framework remains the same but because of event handlers for all the possible routing options, TDD is more suitable in MVC.

Visual Studio 2010 comes with a built in framework for Unit Testing your MVC application and unlike any other project, prompts for a Test project by default while creating a new MVC project. Any of the externally supported frameworks like nUnit or MbUnit can also be used for TDD development with MVC.

ViewState issues and control over HTML

As we know that HTTP is a stateless protocol. To maintain the state of controls between requests, ViewState is used. ASP.NET Web Form applications can get into various performance issues because of ViewState. ViewState Information travels with each request in the form of hidden controls and can quickly choke the server if either the number of controls using view state grows or number of users grows. Diagram 4 shows output of a typical ASP Web Form application and has View State related overheads.

Diagram 4: Typical HTML response of an ASP .NET Web Form page. 

Diagram 5 shows output of a typical MVC application and clearly, is neat and clean as it can get.

Diagram 5: Typical HTML response of an ASP .NET MVC page.

Web Forms abstract developers from a lot of insides of the web server request and response process. If you never had to deal with it then Web Forms is the way to go. In case you need more control over the HTML response generated, MVC is a better choice. The page life cycle of MVC application is completely different from Web Forms. While Web Forms are event driven, MVC has got the power of URL routing and posting form data. Appropriate use of these will substitute all dependency upon ViewState.

Learning Curve

If you are migrating from Web Forms School of thoughts then the learning curve for MVC may be slightly longer. MVC is not good or bad; it’s just different way of programming that requires a completely different mindset to develop applications. With MVC, you experience gain the good old flavor of the web; that is stateless activities, full control and more responsibility for everything.

Diagram 6: Request handling difference between Web Forms and MVC.

Incoming request in MVC is handled by the URL route and then selects the appropriate Controller to further handle the request. Basically there is no concept of page life cycle in MVC. This non event driven model makes it more fine grain and different from legacy ASP.NET Web Forms. There are lots of step by step tutorials available at http://www.asp.net/mvc.

Server Controls

Server Controls is assumed to be the power of ASP.NET Web Forms. It provides the required reusability and rapid application development. Web Forms supports an enormous marketplace of custom user controls, many of them are exceptionally refined and save huge amounts of work. On the other hand, a MVC View does not use the runat=”server” tag. The life cycle of a MVC page is completely different from a traditional Web Form page. If at any stage you feel that you need to use runat=”server” tag or enable the ViewState, you may have to relook your design. ViewState and postbacks are against the MVC architecture. Having said, you may still reuse all the server controls that do not require post back and ViewState. MVC has got the power of URL routing and posting form data. Appropriate use of these will substitute all dependency upon Server Controls and ViewState. Also, there are extensions to ASP.NET MVC to help developer community to build rich user interface in ASP.NET MVC using the reusable controls. Here is one such link on the CodePlex

http://telerikaspnetmvc.codeplex.com

Search Engine Optimization

In MVC, the request is not a physical page on the server; it’s actually a method of the controller class. Web Forms assume a one to one mapping between request and a physical resource on the web server. “http://yoursite/Home/default.aspx” in Web forms assumes that there exists a page called default.aspx on the server. This limitation does not allow having search engine friendly names. On the other hand, MVC uses smart URL routing which allows better names for SEO purpose. For example, typical urls from WebForms are like http://server/Products.aspx?Category=123 which is not only easily hack-able but also not so human and search engine friendly (We really don’t know what Category 123 means). However, with MVC the typical url is http://server/Products/household which is easy to understand by humans as well as search engines.

If the application in consideration is an Internet application and requires good Search Engine Optimization (SEO) to keep up with competitors, then MVC can be considered. Because in that case the longer learning curve has a business value attached to it.

Conclusion

If you are an expert with ASP.NET Web Form programming model, it will take some time before you can be equally productive with MVC but once achieved it is worth the effort. Also, MVC is an alternate to ASP.NET Web Form development and not a replacement. Both these frameworks are going to stay in parallel and mature with time. While I am writing this, there is already discussion happening for the next version of ASP.NET MVC 3. Over the next few years, MVC will develop and catch up with Web forms and will be a strong contender for shaping the future of Web.

Glossary

References

http://www.asp.net/mvc

http://www.msdn.microsoft.com