If you missed my MVC presentation at January's Jax Architects meeting, let's just say that you missed more than a "Hello, World!" demo application and let the rumors do the rest.
Suffice it to say that when I was at South Florida's Code Camp on February 2nd, Jeff Barnes was STILL talking about my demo project.
I hope this piques your interest and you come to the next Jax Architects meeting, scheduled for February 26th. Jeff Barnes is scheduled to talk about the features in Visual Studio Orcas that are specifically applicable to architects and, having seen a portion of his talk at South Florida's Code Camp, I can tell you that it's a very densely packed presentation. I only hope that Jeff has time to showcase his demos, particularly the ones pertaining to PLINQ and ADO Entity Framework.
Without further ado, let me re-iterate my general opinion about ASP.Net MVC framework expressed as the header to this blog entry: it's a big step towards the true separation of concerns (presentation from data) and enabling easier RESTful development, but, being in the preview stage (not even a beta yet!), ASP.Net MVC is a bit clunky in binding data to views, as well as suffers from a few bugs/problems that make it unsuitable for production initiatives today.
Let's start at why MVC is a big deal right now. When I first heard about MVC, I thought to myself "Haven't we already seen this on Patterns and Practices site? It's where
people that are a hundred times smarter than I am implement so many design patterns that common folk like myself gets lost and starts thinking about 'olden days of Visual Basic
6 development." That thought turned out to be only partially correct, since this time around Microsoft is committed to bringing MVC framework into the mainstream
development within Visual Studio Orcas. In essence, there will be two separate ways to build a web-based ASP.Net application in the near future: using the WebForms approach
(the only way to build an ASP.Net web app today) and by following an MVC approach (once the production version is ready, that is).
When should you use MVC framework in place of WebForms? Based on my whopping experience with one (limited) application in MVC and hundreds of webforms built, I foresee myself using an MVC framework (when it's production-ready, of course) on:
1. Projects where the true separation of data from user interface is required (the large projects with thousands of items and multiple features pertaining to each item would generally fall into this category; there, we must have a place to centrally control the logic and all of the components).
2. Projects where "friendlier" or RESTful URLs are preferable for accessing products. For example, let's say we want to list the top 10 songs for year 2007. Using WebForms
approach, our resultant URL may look something like
http://www.mytunes.com?year=2007&category=top10
If we were to use MVC framework, that same URL would look like
http://www.mytunes.com/2007/top10
MVC's URL is easier for customers to navigate to and remember, as well as friendlier for RESTful web services. If you are like me and have been living under the rock for the
past couple of years, it turns out that there's more to web services development than the plumbing automatically put in for us by Visual Studio. Visual Studio.Net, beginning
with version 1.0, built all of the web services infrastructure in accordance with the WS* set of standards and uses the SOAP model to achieve that. REST (which stands for REpresentational State Transfer) is an alternative way to build and expose web services. With REST, there are no web methods exposed by the web servers, there are just unique resources accessible on the web. All of RESTful operations represent some way of accessing and manipulating these resources. REST web services are much easier to setup (if you had to wire everything manually, that is) than comparable SOAP services, and many vendors (Amazon.com, for example) are developing both SOAP and RESTful web services on their platform. Note that the "friendlier" look of the URL is not a necessary requirement of REST; RESTful services can still be build with multiple '&' and '=' in the URL, but the 'friendlier' look is considered friendlier for REST (pun intended).
3. Projects where you simply want to feel like you've done it the 'Rails way' or the 'Jakarta Struts way.' Both Ruby-on-Rails and Jakarta Struts are correspondingly Ruby-based and Java-based implementations of MVC frameworks, albeit the Ruby developer at the Jax Architects meeting was somewhat skeptical whether the binding of models to views in ASP.Net MVC matches that same binding in Ruby. I think that the binding is not bad (once the bug not allowing me to bind fully from code-behind is fixed, that is) in a sense that we can pass .Net's custom types (dynamically defined from LINQ statements) into the .aspx page (the view) and bind properties of those types to UI controls. Because of the bugs, I gave this binding a "clunky" rating at the beginning of this entry.
Take a look at the presentation attached--I hope it provides an initial introduction to MVC framework and gives you an idea of how to start using it and where to turn for help.