First impressions of ASP.NET's MVC framework

Find out why you may want to use Microsoft's Model View Controller (MVC) framework instead of Web Forms.

ASP.NET development's presentation layer has traditionally been difficult; simply put, it isn't simple. The event model, for example, can confound even the most experienced developers. For someone transitioning to ASP.NET from a system such as PHP or HTML, the idea of coding to respond to a button click instead of a form posting can be odd. And, of course, the View State has always had major drawbacks.

To address these issues, Microsoft has been working on an alternative for Web Forms called the MVC framework. On September 10, 2008, I attended a seminar presented by Brian Hitney of Microsoft at the Columbia Enterprise Developers Guild meeting. Brian did a good job explaining what the MVC framework is and why a developer would use it instead of Web Forms.

Model View Controller

If the letters MVC sound familiar to you, it's because they stand for Model View Controller, a design pattern that has been around the industry for quite a while now. In this case, the MVC system bakes into ASP.NET a lot of things that developers frequently hand code into their applications to simplify development. For example, many developers end up rewriting something similar to Apache's mod_rewrite system in order to provide REST-friendly (heck, simply "friendly") URLs; MVC works this way as a rule. It also eliminates the code behind system, although you can still use master pages.

MVC breaks up the responsibility of responding to a user request into three functions: the model, the view, and the controller. In this case, the model is the underlying business logic, the view is what generates the HTML, and the controller determines what actions to perform. All of the application's business logic gets put into the model in a structure that you feel comfortable with.

By default, MVC provides what amounts to a small domain specific language (DSL) similar to a networking device's rules list, a system called URL Routing; this is used within the Global.asax file to translate URLs into controller actions. It is possible to replace this with a system of your choice, but the system that Brian demonstrated seemed more than capable for all but the most complex Web sites. It was also clear that if it was preferred to store these rules in a different format or outside of Global.asax, it was entirely possible to put them into an XML file, a database, or wherever you pleased, and simply put code into Global.asax to parse that and load the rules into the URL Routing engine. Once the URL Routing system determines the correct controller to use, it calls the controller and passes on the request data in a format defined by the URL Router's rules. The controller takes the user's input, decides which calls to the model are needed, and makes them, passing along the needed input. It is recommended that the typical controller not be more than a few lines of code.

The view is not supposed to know about any of the underlying details or data structures; it's role is to transform the data provided into HTML output. You can use any view engine you want, but MVC ships using ASP Web Forms as the view. But MVC doesn't use Web Forms, right? Yes, but it is still using the ASP.NET Web Forms parsing of the .aspx files by default. As a result, the views are .aspx files with HTML blended with traditional <% %> and <%= %> tags to produce the output. The transformation of data from the model into HTML is generally handled either by code in the view to generate the HTML, the slipstreaming of pieces of data into hardcoded HTML, or the use of helper functions, which get passed the data and create the appropriate tags with the requested options. This gives the developer ultimate control over the HTML produced, which is a major weak point of the Web Forms system.

How MVC stacks up against Web forms

Some of the advantages that Brian showed MVC to have over Web Forms during his presentation include the following:

  • It's possible to run unit tests on the entire output.
  • MVC is more easily maintained and changed.
  • MVC has cleaner URLs and HTML, which is good for SEO purposes and providing REST APIs.
  • MVC provides 100% control over the HTML output.
  • MVC eliminates View State.
  • MVC streamlines the development process due to the separation of concerns.
  • MVC allows you to "manage for change."

A major drawback

I feel like the view is where the biggest problems in MVC reside. The code looks an awful lot like the classic ASP pages that developers were glad to escape. On top of that, a great many ASP.NET developers simply do not know HTML very well because the Web Controls handled that for them. This means that a shift to MVC would require them to bone up on HTML and CSS. Also, because you lose the Web Controls, you also lose ASP.NET's AJAX functionality. In other words, you are giving up a lot of the power of ASP.NET in exchange for a better way of writing applications.

A hard sell to management

I grilled Brian pretty hard during the Q&A portion of his talk. Overall, I liked his answers, but I felt that it would be hard to make a business case for MVC, unless you have a boss that lets you make decisions at this level. Frankly, few development managers that I know would be thrilled about having an application written in a system that is radically different from "the norm" and MVC certainly fits that criteria. The big stumbling point from a technical angle is the decision to retain the ASP.NET engine by default for the view system. I can understand the decision — it lets Microsoft ship the product a lot earlier and preserves existing knowledge — but I still think that it is a mistake.

A fellow developer's endorsement

I spoke with Chance Dinkins, the owner of and lead developer at Mortal Creations, a Columbia-based Web development company. He has been using MVC since its first release about eight months ago and much of my initial interest in MVC came from him. He gave MVC the following endorsement:

"In my opinion, the MVC framework is by far the cleanest and most productive line of thought that has been built into the ASP.NET platform. It provides a level of control that often leaves developers wanting under Web Forms. Ironically, this is probably the biggest obstacle that it faces when trying to attract existing ASP.NET developers currently using Web Forms because the tradeoff is the removal of drag-and-drop programming. For this reason, it will not suit everyone and the devs working on the project have stressed this. If you like the idea of separation of concerns, test driven development (TDD), complete control over the framework and your output, and the removal of hacks such as View State, then you will absolutely love MVC."

A welcome alternative

MVC is a welcome change of thinking for ASP.NET. Developers from other platforms, particularly PHP and Ruby on Rails, are probably chuckling to themselves right now, since they have had something like this for years, but for developers wedded to the .NET platform, it is a welcome alternative.

MVC is currently in its fifth CTP, and the next release will be a public beta. It is expected to eventually be folded into the .NET Framework, so you can expect that if you learn MVC today, it will have widespread support in the future. The healthy ecosystem around MVC is already growing.


Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.


Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!


Justin James is the Lead Architect for Conigent.

Editor's Picks