I took a break from Silverlight to spend some time with Microsoft’s new ASP.NET MVC framework. It’s one of the features of the ASP.NET 3.5 Extensions Preview, and as such, it offers a tantalizing glimpse at what the ASP.NET of the future might look like.

I felt compelled to write down some thoughts after I got a call from a friend expressing confusion over where Microsoft was headed with their Web stack and wondering how MVC fits into the big picture. My friend heads up software development for a large company that invested heavily in ASP.NET and was one of ASP.NET 2.0’s earliest adopters. He’s feeling a little overwhelmed right now because new products and technologies are rolling out of Microsoft faster than open-source advocates at a Bill Gates keynote.

FWIW, here are my thoughts on the ASP.NET MVC framework.

MVC is Currently Rough Around the Edges

You don’t have to spend much time with the current release of the ASP.NET 3.5 Extensions Preview to realize that the MVC framework is just that–a preview. When you add an MVC view page to your project, the compiler rejects any references to Web controls declared in the page until you use the “Convert to Web Application” command on the page to generate the missing designer file. And the HtmlAction class is way too limited to be useful right now (something the team is working on as we speak). But remember that it is just a preview.

MVC Stands Alone 

Scott Guthrie has published some excellent MVC tutorials in his blog. Here they are in case you missed them:

One of the unique aspects of these tutorials is that in addition to hitting the high points of MVC, they make liberal use of other new features and technologies such as LINQ and ListView. Some folks find this confusing, because it’s hard to follow the tutorials if you’re not up to speed on C# 3.0 and ASP.NET 3.5. Realize that MVC doesn’t require LINQ. In the first MVC app that I built, which puts a pretty presentation layer around some of my model airplanes and jets (see below), the model classes don’t use databases or XML; they simply wrap hard-coded data in custom C# types and provide them to the controllers and views. This increases the signal-to-noise ratio and makes it slightly easier to wrap your arms around MVC.

B-25 Mitchall

MVC Has Pros and Cons

I’m sold on the value of MVC as an aid in unit testing. And the fact that it enforces better separation of logic–controllers to route requests and handle input, models to abstract data, and views to present UIs–in an application is a big plus. (Goodness knows there are way too many ASP.NET pages out there that contain data access code.) I like the mechanism for passing strongly typed data to views. And I like the routing infrastructure and the fact that it decouples URLs from physical locations on a Web server.

But be aware that MVC requires a pretty dramatic rethinking of your app’s architecture, especially if you intend to forego the postback model and handle form submissions as Scott does in Part 4 of his MVC tutorial series. Which brings me to my final thought…

Stateless Pages are Great, But…

Scott’s examples use lots of HTML input elements and a limited number of Web controls such as ListView and Repeater. More importantly, Scott’s examples don’t use Web forms–that is, <form runat=”server”> elements. The benefit is huge: the examples generate no view state!

If you intend to embrace the MVC model and follow Scott’s examples to eliminate view state, you need to be aware that most ASP.NET controls require a runat=”server” form. Unless Microsoft introduces a whole new slate of controls, stateless MVC pages must forego the control-centric model to which ASP.NET developers are accustomed. No more GridViews, for example. That’s not necessarily bad, but it’s a very different model than the one we use with ASP.NET today.