In March of this year, we released ASP.NET MVC. Since then, many ASP.NET developers have been perplexed about MVC. Many developers aren't quite sure what MVC is and what it means for ASP.NET developers. Many more developers have some level of understanding when it comes to MVC but are not sure when it should be used and why. This post will hopefully shed some light on some of the confusion surrounding MVC.
A Brief Overview of ASP.NET MVC
ASP.NET MVC is a framework that adds support for the MVC design pattern to ASP.NET. Therefore, in order to really understand what ASP.NET MVC is, you need to first understand what MVC is.
MVC is an acronym that stands for Model / View / Controller. MVC is a programming architecture that aids developers with separating different components of an application. Let's review each component of MVC individually as they relate to ASP.NET MVC.
The model in an MVC application stores the application data or state of the application. The model is often a database, an XML file, etc. However, because the model is designed to encapsulate the data layer in the application, you will typically not see the data source correlated with the model with regards to MVC.
In an ASP.NET MVC application, the model typically uses LINQ to SQL or LINQ to Entities.
The view is the user interface that your site visitors to see data from your model. In an ASP.NET MVC application, web forms (ASPX pages) are typically used to display the view, but there's a significant difference between an MVC view's page and a typical ASP.NET web form. Most specifically, an MVC view doesn't use the typical postback model and the page lifecycle that you are used to when using web forms doesn't exist with MVC views.
You don't have to use ASP.NET web forms as the view engine for MVC. Check out MVC Contrib on CodePlex for more information.
It's easy to make the mistake of thinking of the view as the component in MVC that handles user input and controls the interaction with the user. In fact, it's the controller that takes on this role. The view is strictly limited to displaying data from the model.
The controller is responsible for handling the interaction with the user, for communicating with the model, and for determining which view to display to the user. The controller is derived from System.Web.Mvc.Controller.
The controller defines one or more actions that can be invoked using a URL entered into a web browser. For example, consider the following URL:
A request such as this one would be handed off to the ProductsController where the display action would be invoked. In this particular case, that action might then display a view of product number 43. The routing of the URL to a particular controller is configured using routes that are defined in the global.asax of the MVC application.
For more detailed information on controllers and actions, see the MSDN documentation.
What exactly is an action? An action is simply a method of the controller class that meets a few specific requirements.
- An action method must be public
- An action method cannot be overloaded
- An action method cannot be static
It's important to keep security in mind when developing your action methods. For example, based on the above URL, one could conclude that browsing to http://www.mysite.com/products/delete/43 would delete product number 43! The Authorize attribute can be used to restrict access to a controller's actions. See http://msdn.microsoft.com/en-us/library/dd381413.aspx for more information.
Benefits of MVC
In order to maintain state in an ASP.NET web forms application, ASP.NET uses encoded data in a hidden form field via a feature called viewstate. Viewstate does pretty well at providing the illusion of a stateful application, but there are times when problems are encountered. For example, in large applications, viewstate can become very large. Large viewstate not only increases your payload across the network, but it can also impact your search engine ranking by pushing readable page content far down in the rendered code.
The problem of large viewstate was greatly improved in ASP.NET 2.0, and you can expect even more improvements in ASP.NET 4.0.
ASP.NET web forms developers also have to take the page lifecycle into account, and dealing with when to do certain things can be as much or more frustrating than figuring out how to do something. MVC does away with this kind of frustration because it is truly stateless. Postbacks and the web forms page lifecycle no longer exist.
Another advantage when using MVC is that it allows for full control over the rendered HTML. In a web forms application, HTML code is rendered in large part by server controls, and developers have relatively little control over the code that is generated. The HTML code in an MVC view, on the other hand, is entirely controlled by the developer of the view.
MVC also lends itself well to a separated approach to development. One developer can work on the controller class while another developer works on the view. This design methodology also aids in testing. It's extremely difficult to test one particular piece of a web forms application because of the reliance of all of the other controls on the page and the managed runtime. An MVC application can be tested much more easily and efficiently because the model, the view, and the controller are all separate components.
You can find a great overview of the benefits and drawbacks of both MVC and web forms in Dino Esposito's Cutting Edge article. More great information is available on Shiju Varghese's blog post.
MVC or Web Forms?
Now that you've got a basic understanding of what ASP.NET MVC is and what it offers, you may be wondering if MVC is the way to go with your future ASP.NET applications. Let's look at a few scenarios that might help you decide if MVC is right for your next ASP.NET project.
Choose MVC if . . .
- You are well-versed in the architecture of MVC. If you aren't comfortable with how to design a controller, MVC probably isn't a good choice.
- You want full control over the HTML that is rendered in the browser and you can afford the development time and overhead to do all of your own markup.
- You need to create efficient unit tests for your user interface without the overhead of the entire managed runtime, etc.
- You want full control over how your URLs are formed.
Choose web forms if . . .
- You are not familiar with designing MVC applications.
- You need to minimize development time.
- You want a feature-rich user-interface (such as GridViews, etc.) to display data with rich interaction without substantial development investment.
- You are already invested in server controls, either from your own development or from 3rd parties.
These are just a few of the reasons why you might choose one framework over another. Obviously, no one can tell you what decision to make for your application. Ultimately, the decision is up to you, but hopefully the information I've provided here (along with some good links) will help you to decide as you approach your next project.