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
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<T>, 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.