18th August 2009

Why .NET MVC? (and why should we care?)

Having previously written about the highs and, perhaps more importantly, lows of working as a .NET developer. This article will continue the trip into Microsoft World, only this time it’s to the land of MVC.

Recently Microsoft was brought back to the attention of many, not just for the interestingly named Bing, the Yahoo ‘partnership’, or the delights of a browser choice screen. Developers with their ear to the Redmond ground became aware of something being touted as the next big thing for Microsoft .NET development – ‘MVC’.

Although announced some time ago many users left it aside until a more complete release. Now however, with another release on the horizon and many examples of sites that use MVC (including the particularly well known StackOverflow) it is certainly something people are using on a daily basis.

As would any eager developer I tried the beta, had fun installing the final release and have now been involved working with and using it. My impressions so far are good. It would appear that Microsoft have addressed those amongst us bemoaning the issues of WebForms. For example lets take a look at a collection of comment snippets from the “don’t hate me post”:

Markup

When I first tried the winforms model after being a ASP developer for many years part of me loved it’s rapid development but I always felt a bit dirty when looking at the source code... Chris Morledge

A key point really here is that the abstraction that was provided by .NET webforms was/is, for some, a step too far. The masking of actual html output behind server controls, although rapid, caused friction between backend and front end developers. A carefully crafted html design would often be bounced back and forth as developers implemented using controls.

Conversely MVC is far closer to the metal in terms of both your html and indeed your required knowledge of the way the web works. Although views are often output with html helpers these are far easier to customize than creating your own Custom Control Adapters. With .NET MVC, webforms Developers will be reminded that there is no inherent state on the web (and perhaps hopefully of the separation between back and front end development - I've never been a fan of auto-generated javascript. It can lead to an over reliance and ignorance of approaches like hijax).

Tutorials Available

All of the training material and tutorials will show you how to do it the easy way Tim Snadden

This has been an issue I've had with some Microsoft materials for a long time. Reading about things like <asp:SqlDataSource /> controls always left a bad taste in the mouth in terms of reusability, testability and layered architecture. However, some of the materials on the MVC site are bucking that trend.

Working around .NET

we crafted our own pseudo MVC framework cmv

Similarly to cmv many devs have crafted their own implementation to separate presentation and logic concerns. I have previously discussed using XML and XSL for this. However now we don't have to, or if we do want to with .NET we can at least work from an open source framework (yes MVC is on an open license) with a multitude of available view engines or even create our own view engines.

Seemingly few people who dislike the idea of using Microsoft technologies are aware of the Mono Project. An open source .NET implementation with an IDE (Mono Develop). For those of you who would like to know more I thoroughly recommend Miguel de Icaza's appearance on the stackoverflow podcast. Mono is also not as open to legal attack from Microsoft as people may think.

So how is it done?

There are already many resources for learning .NET MVC, not least the asp.net/mvc site itself. In brief a project will contain:

Views - Implementing IView (guaranteeing a Render() method)

The default MVC project from Visual Studio includes a number of sample views. These are instances of the ViewPage class. Data can be passed to these views by the controller through the ViewData property bag. However if you change the type to ViewPage<T> these views become typed views. For example you may have a 'CustomerViewModel' object (encapsulating view related information for a Customer entity/Customer BO) and so create a ViewPage<CustomerViewModel>. In this case the View has access to a ViewData.Model which will be a typed customer view model instance.

In terms of team breakdown these '.aspx' pages will be where the html is and where designers may wish to make their mark.

                <%@ Page="" Title="" Language="C#" 
                    MasterPageFile="~/Views/Shared/Cargowire.Master" Inherits="System.Web.Mvc.ViewPage<IEnumerable
                      <BlogPost>>" %>
              

fig. 1.0

Controllers - Implementing IController (guaranteeing an Execute() method) or generally inheriting from the Controller class

The Controllers job will be to direct the traffic based upon the request, including processing actions (using methods that return ActionResult) that map to the 'action' url part.

              // GET: /Home/
              public ActionResult Index()
              {
                ... // e.g. Commands to return an IEnumerable<BlogPost>
              
                return View(blogPosts)  // returns ViewResult(IView) (Ultimately inherited from ActionResult)
              }
            

fig. 1.1

Models - Component(s) for maintaining state

Models can take many forms including business objects mapped to sql through linq to sql or of course a number of layers including services, repository and business object classes.

Routes defined in Global.asax

                routes.MapRoute(
                  "Default",                                              // Route name
                  "{controller}/{action}/{id}",                           // URL with parameters
                  new { controller = "Blog", action = "Index", id = "" }  // Parameter defaults
                );
              

fig. 1.2

The Process

Figures 1.1 - 1.3 illustrate a simple example using .NET MVC. In this example a route has been defined for the blog controller and the action 'Index'. When a site visitor hits 'http://site.com/blog/index' the .NET MVC Framework will invoke the Blog Controller's Index method. This method will ultimately retrieve an IEnumerable<BlogPost> instance which can then be displayed within the typed view. For example the view content could be:

            <% foreach (var post in Model) { %>
              <div>
                <h2><%= ViewData.Model.Title %></h2>
                <p><%= ViewData.Model.Body %></p>
              </div>
            <% } %>
          

fig. 1.3

In this simple example the BlogPost class is a business object that could well map directly to a persistant storage entity. However in a more fleshed out system it could be that the View is typed to a 'BlogPostsViewModel' that contains items that can be enumerated for listings, plus items for category description etc.

Final Thoughts

This article has attempted to do two things. Firstly to act as a sequel to "Don't Hate me for my .NET" but secondly to introduce, at a basic level, .NET MVC. The example given is to provide a flavour of MVC development on the .NET platform and could be expanded to cover a number of other currently favoured approaches and technologies including more detailed assessment of the Model and how the dependencies interact. However, that may be for another day.

The community around .NET MVC is already thriving with a plethora resources, many of which I have linked to when possible above.