Why ASP.NET MVC is better – using ‘Hello’ as an example

In this second post about Hello (the first can be found here), I’m going to use one of the more complex portions of the app, the event front page, to illustrate some of the various parts of MVC which make writing web apps more intuitive.

The web app of the Hello project was written in ASP.NET MVC, which is Microsoft’s latest addition to the ASP.NET framework. It uses the Model, View, Controller design pattern and is influenced heavily by frameworks like Ruby on Rails.

To produce the event page, there are several stages that the app goes through – for an awesome outline of the ASP.NET MVC Request-Handling Pipeline, see this poster. Firstly the URL is routed through to the correct controller. We decided that we wanted the front page for an event to live under a really simple URL: /eventslug, where eventslug would be a short string to uniquely identify the event. For example, for the Future of Web Apps event we might have the URL /fowa. From the event page you can search the users at the event, and we decided the intuitive URL for the search should be /eventslug/search. You configure the URLs in the Global.asax.cs file as follows:

From here the framework calls an action on your controller. If you’ve not started using MVC yet, a controller in an object that inherits from the abstract class System.Web.Mvc.Controller and an action is a public method of a controller. The signature for our action that will be called for /fowa is:

We call it Index because that’s the default action that we specified in the routing configuration. The framework will automagically map the value of the eventslug argument to the value that matches the {eventslug} portion of the URL; In the case of /fowa it will be the string "fowa"*.

Then, in our action method, we grab the data relevant to the event with the requested event slug, and pass it to the view by calling View().

Calling the View method with theEvent as an argument means that in the view, the Model property of the ViewPage object will be the theEvent that was just retrieved from the repo. In MVC the view is an aspx page without a code behind class. The view is actually a ViewPage<T> object, which is a subclass of the old Page object that you’re familiar with from WebForms, where T is the type of the Model property. What this means is that in the view we get intellisense on our domain object.

In the view we also have complete control of our HTML, which was invaluable for this page as we had to get the layout just right in all the major browsers. So we just iterate over our rows of seats rendering the smiley.jpg image for an empty seat (sat == null) and when someone is in a seat we render their Twitter avatar.

This is much more intuitive and clear than having to create a user control class which is then dynamically instantiated in the code behind and added as a child control of an ASP TableRow, which is then in turn added to an ASP Table, etc. Your code in front would of been basically one line…

… Totally hiding the complexity in the code behind, which would probably have been a mess of data access code and layout styling knotted together. Which is what you would have done in WebForms.

So why is this better? There are probably two key differences between WebForms and MVC. Firstly, separation of concerns: MVC encourages you to separate out your domain model from your UI from your URL routing. WebForms actually makes that quite difficult; if anything, the code in front/behind paradigm encourages the reverse. Secondly, no unnecessary leaky abstractions: WebForms tries to hide from the developer the fact that he is working in a world of string manipulation over a stateless protocol. In the simple case this can work well, e.g. the classic click-the-button-to-make-the-label-say-hello example. But in the real world, the abstraction soon gets in the way, and you end up having to work really hard to achieve something quite simple. In MVC there is no abstraction to battle against, you have complete control of all parts of your web app. I’m going to put myself out there and say that MVC should be seen as a replacement to WebForms, as I don’t think there are any real world cases when MVC is not the right choice.

* this isn’t strictly true, the arguments of an action can be mapped from 1 of three places – the URL, query string paramenters, or form values.