Microsoft ASP.NET MVC

By now we've nearly all heard of the ASP.NET MVC framework available in CTP form. The Model View Controller architecture has been around for quite some time but more popularly in the desktop world. Java has seen its share of MVC web frameworks over the years and just a few years ago Ruby on Rails crashed the party with its own MVC implementation for a rapid development environment. Once Ruby on Rails hit, all of a sudden MVC was all the rage. It wasn't long before these frameworks became available as extensions for ASP.NET. Microsoft has now joined the party with an official feature due towards the middle of 2008. In the last few weeks the ASP.NET team has shipped a CTP release for feedback and to get people started with the technology. I've looked at it quite a bit myself and I'm loving what I've seen thus far.

There are a number of reasons to be excited about this framework. Some of the biggest are separation of concerns, testability, and performance.

Separation of concerns allows you, the developer, to create self aware components that don't heavily depend on another un-related component to function. Think about removing the logic of your postback event in ASP.NET 2.0. Take that code and move it somewhere more centralized that will be used by similar web views. That concept is the relationship between the Controller and the View. The View should simply display something while the Controller should tell it what to display. The Model describes the data and is used by your Controllers and Views as something I like to think of as a transitional object.

Testability is a major concern with most developers these days. Currently automated unit testing is nearly impossible with the current Web Forms architecture present in ASP.NET. Sure, you can unit test your data and business layers. However, once these layers reach the presentation layer, testing expected behavior just isn't possible in an automated fashion. The ASP.NET MVC framework allows testability through the separation of concerns along with the way a Controller will dictate which View is rendered. That functionality allows for easy testability.

The final reason I'll discuss here is performance. ViewState is a piece of magic all too often by the Web Forms architecture and simply is a bloated method for persisting data across HTTP requests. The ASP.NET MVC framework will remove this dependency and will provide better performing environment for our web applications.

I'm in the planning stages of a new project and really investigated whether I should begin ASP.NET MVC development. Since it's so new I'm not going to risk it but I encourage everyone to keep an eye on this project. I'll definitely be doing that and will be all over a release closer to RTM.

Resources:
ScottGu - MVC Tag
Phil Haack - ASP.NET MVC PM

kick it on DotNetKicks.com

5 Comments

  • Great, this post gives me a little clearer understading of why I should start setting my eyes on ASP.NET MVC

  • If you're looking for a mature, stable (.NET 2.0 too) MVC implementation under ASP.NET, check out MonoRail from the Castle Project:

    http://www.castleproject.org/index.html

  • Hey Chris, excellent post. I too decided that MVC is a bit too new for a major project. However I have been using MVC to work on smaller, more easily maintained projects. I don't know if I just really like the new framework or it is making things easier but I seem to be developing much faster using MVC.

  • Denny,

    I'll definitely be doing the same. I think if you have a small project that's for internal usage only, using the MVC framework is a good idea. Not only will you get a leg up on the technology in its early stages, but you'll be in a prime position to migrate that code base to the final MVC release when it's available. I certainly think that the MVC framework will have a huge impact on ASP.NET.

    My initial exposure to the framework was with Ruby on Rails. That was what I liked most about Rails and I'm thrilled to see it as a future supported feature of ASP.NET.

  • I'm mostly excited about HttpRequest and HttpResponse being interface based now. Much easier to mock those!

Comments have been disabled for this content.