jb's Blog

Archive for February, 2009

Loving ASP.NET MVC

 I thought I would share a few thoughts about ASP.NET MVC, as I have really enjoyed working with it over the last year. As you are likely aware this has been an “out of band” release, but is going to be bundled with .NET 4.0 so we can expect it to be a mainstay in the .NET world going forward.

While not the most sophisticated pieces of technology out there, it stands out as a great example of Microsoft “getting it right” in recent times. The openness of the team, the responsiveness to feedback and the good design of the framework are what stand out for me.

For the latter part of last year, JD and I spent some time building out a reasonable size ASP.NET MVC implementation for Givealittle.co.nz which gave us some interesting insight into building a real world app on the framework.

The solution itself comprised of around 10000 lines of code, a suite of ~600 unit tests and is broken into 6 projects (Common, Model, Security, Web, Routes and UnitTests) – an integration build takes ~1 minute on our build server.

So how did it work?

Back when we first kicked off the project, the bits were at Preview 1, when we finished they were at Beta, now they are at RC. So quite a bit has happened in between, but the solution hasn’t changed too much architecturally and looks logically like this:

As you can see we deviated a bit from the “out of the box” offering with MVC on a few fronts:

We chose to use NHaml for our View Engine for two reasons, first we really liked the symmetry with Rails, and secondly it made it feel more connected to the HTML and CSS being used in the solution. If you are in the same camp you should give NHaml a look. There are some other interesting view engines available out there so remember to shop around and find one which gives you the best fit.

For the RIA aspects, we used jQuery – a totally awesome JavaScript framework which if you are not using – you should be! And of course we totally loved seeing the team pick up on this as well so this is actually now “out of the box” as such

We chose to use LightSpeed (of course) for our domain model, as this offered us a lot of advantages in getting up and running quickly (we generally modelled on paper, set up the entities in the database and then code-gen’ed our entities through the Visual Studio designer). All the behavioural aspects of the model were then added through partial classes. Another big advantage we got from using LightSpeed entities was the model validation which we used to manage a lot of the validation burden for form unbinding since most of it targeted new or existing entities in the model.

We used WCF to handle the distributed aspects of the solution (mainly in dealing with payment providers and the like). As most “real” solutions these days are likely to have some kind of distributed resources that they need to work with I think this would generally be considered “out of the box”

So what did we learn?

1. By itself, the framework alone is not going to cut it for most real world apps. And by this I mean there are plenty of optimizations you are likely to make when building out an application on MVC which mean that you will ultimately develop your own “wrapper framework” which is based on MVC. Example of this for us were handling routing, adding extensions for link generation, adding in custom action results, adding in custom filters for concerns such as security and so on.

2. The model binding capabilities are great. Learn about how to extend these to more effectively manage your incoming data.

3. Routing can quickly become a PITA when your URL structure is not {controller}/{action}/* – most of the samples and guidance out there seem to prescribe an overly generic site structure – nice if you can handle it, but generally there are going to be plenty of edges to deal with. In Givealittle we had a custom structure with many of the concerns being duplicated across multiple domains in the site. e.g. Adding a blog post to Organisations and Projects – clearly we didn’t want to have the functionality duplicated in both of these controllers to save a few additional routes. The new routing API is great, and a welcome addition to the framework, however can be quite unwieldy for adding routes manually with the use of Constraint collections, Defaults collections and the like.. We simplified this for ourselves by using a helper which would build up a route on our behalf based on this style:

.Get() indicates it is a GET request for the resource such as /login which would then map to the Home controller, Login action.

So how did it compare?

Having now built solutions using WebForms, Monorail and even Rails, there are a number of clear benefits I think can be gained by using MVC.

These would be:

• Well suited for internet facing solutions where tighter control over the HTML/CSS matters
• Improved quality from higher test coverage – the controllers are easily testable
• Paired with the Routing framework you get great control over how the site structure is mapped
• Simpler – there is a lot less going on with ASP.NET MVC compared to say WebForms so it was much easier to be productive and later on much easier to refactor. Compared to say Monorail, the lack of a lot of the “out of the box” infrastructure was also useful as there was less to contend with up front. I think this makes it more approachable for developers.

Of course you are closer to the “bare metal” so you do have to have a better understanding of the web. Keep that in mind.

If none of those benefits apply or are high priorities, then you might find you are best off sticking with something else, but I reckon MVC is the way forward for building web applications on the .NET framework

Introduction to Oslo

Thanks to everyone who came along to the session on Oslo last Thursday at the Auckland Connected Systems User Group – was great to be there for the first time

As indicated during the session, Ive uploaded the slide deck and the M file we used during the quick look at the M language for you to have a play with – remember to download and install the Oslo Jan SDK to make use of these.

The Oslo Dev Center is the place you want to go for all things Oslo or M related, and also check out what some of the bloggers out there are doing with M so far..