Foray into ASP.NET MVC

I’ve been working with ASP.NET MVC for the last week. It has seriously renewed my hope in a Microsoft web product. I am among the snobs who think ASP.NET WebForms is a terrible leaky abstraction. MVC changes all that by assuming that web standards and semantically meaningful markup are not only desirable, but necessary for a web application. At first blush, it reminds me an awful lot of my previous experience with symfony, the popular PHP web framework. Splitting models, views, and controllers into distinct and decoupled files and classes is a very powerful concept, and buys the developer tremendous flexibility when changes on any of those tiers are mandated. A database change need not break the view; markup change need not affect page logic. It’s a beautiful thing. The routing system in MVC is also very powerful and effectively creates a paradigm shift for how we view URLs. MVC treats URL requests as logical paths to information as opposed to physical paths to pages. It does this by mapping specific URLs to controllers that have actions which contain the page logic to render given views. This is especially significant for SEO purposes where URLs are often crafted to communicate as much relevant content to search engines as possible. It also makes traditionally cryptic URLs far more reader friendly. (For example, the URL to this post contains the route /2009/10/foray-into-asp-net-mvc, which is more understandable than ?y=2009&m=10&title=foray%20into%20asp%20net%20mvc.) Routes are specified in the Global.ascx.cs file. The URL helpers that come with MVC allow internal links to be specified by Controller/Action, but renders them as specified in the global routing table. If a URL needs to change for a given resource, instead of finding all references to it in the source tree, only the routing table needs to be updated. My favorite feature of MVC so far, though, is the simple fact that it doesn’t muck with my markup. One thing I loathe about WebForms is that it insists on re-writing my HTML and making it damn near impossible to write standards-compliant code and adhere to web development best practices. In MVC, when I assign and id to an element, that’s the id it gets – not some hogwash like _ctl00_ucPrimaryNav_primaryNavigationTable_ctrl1_lnkPrimaryNavigation_. (WebForms is kind of like the government. When it says “I’m here to help”, run away screaming.) This one tiny feature also frees up ASP.NET developers to leverage robust Javascript frameworks like jQuery and Prototype, feats that are not impossible in WebForms but require significant jury-rigging. The single-form-per-page has also been eliminated in favor of traditional HTML forms, which has always been a personal gripe of mine. (There are many scenarios where multiple forms on a page is a good idea.) In place of the one genuinely useful feature of WebForms server controls, data binding, MVC introduces the concept of a strongly typed ViewModel that acts as the data source for a given view. This is a common development pattern gaining tremendous momentum in WPF circles (it is officially called Model-View-ViewModel in WPF and Silverlight), and it allows developers to interact with an object that contains all of a view’s data, but is not itself the view. WebForms violates this pattern by confusing the view with it’s own data, but MVC encourages it by supporting views that derive from System.Web.Mvc.ViewPage, where T represents the ViewModel object to which the view will be bound. Fields in the view have IDs and names that correspond to properties in the ViewModel. They are automatically populated with the values of the ViewModel at runtime when the controller renders the view. This also provides a layer of encapsulation for the developer to leverage, masking the actual implementation of the data model, since model objects are not directly exposed to views. In fact, all that a view need know about is the interface that a ViewModel exposes, which is typically composed of simple types like strings, numbers, and boolean values. The view is agnostic to the data structures behind the ViewModel. I am thrilled that Microsoft is supporting the MVC project as a viable alternative to WebForms. As I learn more about the framework, I will be sure to add more posts, including some code samples.