Who Cares About ASP.NET MVC?
More and more people are beginning to ask me this question: Why should I care about ASP.NET MVC?
Joe Six Pack and ASP.NET Web Forms
As much as the .NET elite like to complain about ASP.NET Web Forms, the bottom line is that many Joe Six-pack corporate developers are very happy with it. Most of their job consists of building data entry forms as quickly as possible.
Web Forms easily, though maybe not elegantly, achieves this goal:
- Need a list of data? Just drop a gridview.
- Want paging? Fine, just turn it on.
- You want validations? Just drop a validator.
So many features are provided for “free”, and if there’s something that it cannot do there’s a thriving third-party ecosystem. But with all these benefits, ASP.NET Web Forms are not perfect.
Are Web Forms Evil?
While Web Forms are not evil, they do have some issues:
- ViewState: ViewState is a wonderful abstraction when it works properly, but sometimes ViewState can grow into a monster. It can become bloated and seriously compromise the performance of your application. While it can be turned off, most developers are not aware of how to do that without breaking other parts of the application.
- Mangled HTML and URLs: Because the HTML in Web Forms is spit out from controls, you do not have control over the end-product. If you want a div-driven layout, for example, you better hope that your control supports that option. And if you want to access your control IDs via JavaScript, you will have to jump through hoops. As for URLs, they will often be rendered as JavaScript post-backs rather than true URLs.
- Event System Complexity: The idea of building the web around an event-based system probably seemed very natural to Microsoft given that Visual Basic and the Windows API are so event-driven. And it did make the transition simpler for existing Microsoft developers. But the sheer number of events that be fired along with keeping track of which events fire when is often confusing and overwhelming to most developers.
So, if Web Forms has these problems, let’s see how ASP.NET MVC solves them.
Does ASP.NET MVC Solve the World’s Problems?
ASP.NET MVC does not solve every problem, but it does give the developer much finer control of their application. I like how Scott Hanselman described ASP.NET MVC as “Web Forms Unplugged”:
This is a not just a different tune, but a whole different band playing all new music. Not everyone will like the music, and that’s why the world has more than one band. This is a Good Thing.
I like to think of ASP.NET MVC as the raw, acoustic version of the more heavily produced and multi-layered ASP.NET WebForms we use today.
In other words, you do a lot more yourself. And what does MVC give you for all this extra work?:
- Testability: Because ASP.NET MVC enforces a true separation of concerns with the MVC pattern, you can easily test by calling methods on your controller just like the real application will do in production.
- Clean URLs: URL routing is baked into ASP.NET MVC so it’s trivial to make URLs look like www.mysite.com/blog/post/2 rather than www.mysite.com/blogpost.aspx?id=1. Cleaner URLs result in users being able to browse the site more intuitively and allows google to better index the site.
- Clean HTML: In ASP.NET MVC your HTML is not spit out from various controls, instead you roll your own. This is more work, but provides lots of benefits like manageable Client IDs for use in JavaScript functions and leaner HTML for client downloading and Google indexing.
All of these benefits are great, but with the finer grained control, you do lose some of the rapid app development, or RAD, that comes with ASP.NET Web Forms.
Conclusions
At the end of the day, ASP.NET MVC is an excellent new tool for the tool belt. There are situations where I would use it, and others where I would still use Web Forms. At the end of the day, it’s nice to have options.
If you are considering one or the other, I would summarize with the following:
- If RAD is important to you, and you do not need fine control of HTML or URLS then choose Web Forms. This will typically be the case for internal corporate apps.
- If you need fine control of URLs or HTML and testability is important to you, then choose ASP.NET MVC. This will more-likely be the case for public websites.

