Dan Maharry

Writing about web development since 1997

First Impressions of MVC

[In which ASP.NET MVC is initially judged by its beta 1 cover, reappraised after the first few weeks on development, and pigeon-holed for now post-RC1. Or rather, here are my thoughts on using ASP.NET MVC to build a web site.]

Just before Christmas, I was asked to build a web site using the nascent ASP.NET MVC framework, which was in beta at the time. Two months later, it’s now at release candidate level and the final build is expected to go gold in March, so there’ll be the inevitable tweaking here and there, but for now, here are my general thoughts and impressions of using MVC as the ASP templating system rather than Webforms.

“Oooh shiny” turns quickly to “developer inertia”

It’s noticeable that of the two new ASP.NET packages, with the dynamic data stuff being the other, MVC has had by far the most hype. The alt.net crowd is very vocal when it wants to be and as webforms does not always play nicely, they were very happy to see MVC appear. The large amount of good will made me keen to use it to see what all the fuss was about: it produces clean code, is lightweight, creates SEO-friendly URLs, and stackoverflow runs happily on it, so those are quite good reasons. My jackdaw tendencies to grab anything shiny came to the fore. Then I started using it and developer inertia took hold.

One of the side-effects of MVC is that it also forces you to relearn foundation level knowledge - HTTP verbs, proper semantic, standards-compliant HTML (ok, not that tricky, but go with it), javascript (JQuery, Moo, MS AJAX or whatever flavour of library you care to learn on top of that too), file streaming and the rest - which WebForms shields you from. MVC currently (RC1) does you no favours on that line. Want to enable uploading a file to the site? Better get out your best file streaming code. Want to implement a tab panel or a wizard? Start searching for javascript libraries. Find yourself trying to implement the SelectedIndexChanged event on a dropdownlist? Can’t do it - there’s no server-side event model with MVC. I’ve mused on developer inertia before at a time of upgrading systems but not really experienced it when trying something new. It’s an odd feeling to relearn how to code things that a simple webform control would have done for me in seconds. I also know I’m coding quite naïvely again while I find my mental feet with the new way of thinking about site construction that MVC forces you to have.

Documentation

And some of that is due the lack of documentation around. Or, rather, the abundance of out of date blog posts detailing ways of accomplishing tasks in some CTP that have since become obsolete in more recent builds. Of course, the wealth of accurate MVC knowledge will only get better with time. For my part, I got the most value from the Walther\Litwin pair programming vids on asp.net, Phil Haack’s talk from PDC ’08 and the early access PDF of ASP.NET MVC in Action available from Manning Publications. The latter in particular pulled together several facts about the basic conventions for MVC development that I hadn’t really seen anywhere else, so I’ll definitely buy that when it’s in print. Props to Jeffrey Palermo, Ben Scheirman and Jimmy Bogard for that. Secondary thanks to the people on stackoverflow for coming across the problems I was having before I did and presenting solutions. Again, some of the answers are pitted against previous builds but if the solutions there didn’t work, the SO folks answered very promptly any requests for an update. They would be my first port of call now if there is an MVC problem that I can’t solve myself.

Intellisense

A by-product of doc-light frameworks is a heavier reliance on intellisense. We all know that javascript and latterly JQuery intellisense has been introduced into Visual Studio which is good, but currently the MVC intellisense seems to have been gazumped first by the need to recompile your site each time you need it to work in a new view, and by anonymous initializers. A lot of parameters are simply of type object which, unless you spot a matching blog post or some code in a video, you probably don’t realise means using an anonymous object initialiser and strings.

Case in point, Html.ActionLink is one of the more useful HTML helper functions in MVC, referencing the routing table for the site and generating the correct URLs for controller\action\parameter combinations on your site. Want to switch from extensionless URLs to .mvc or .aspx or back again? ActionLink notes the change and renders URLs appropriately. (v.g.) However, it has ten overloads.

MVC Intellisense for HTMl.ActionLink

Based on the intellisense caption pictured above, how would you complete the call to ActionLink? As it turns out, it looks like this

<%= Html.ActionLink(
   "Development", "development", "about", new{}, 
   new { accesskey="5", Class="darkredcaps", 
      tabindex="7", title="About our development work"})

Once you see it, you go ‘ah!’ (Apart from the fact that the HTML class attribute must begin with a capital C else C# throws an error but as there is no standards checking inside server markup that’s OK.) but here’s hoping that Microsoft improves intellisense somehow to make it more obvious.

On the bright side

If this all seems a bit negative, I must also emphasize that there are definitely many bright sides to MVC. Full control on what a site presents to a browser is an obvious highlight but you have to like the fact that LINQ (to SQL or to Entities) is such a quick and easy way to create the data access layer, or ‘Model’ in the lingo. (Using some variant of the ‘repository pattern’ in your code is also a time saver looking forward. Ta to Rob Conery for that one.) And if you don’t like LINQ, then it’s easy to switch it out later on or right away as you prefer.

Another great and welcome addition for newcomers is the sample site created in the sample MVC. It does a great job of presenting sample code and, more importantly, includes the account controller with the code needed to implement a site using the ASP.NET membership provider - truly a gift. No roles, profiles or use of other providers, but those are much more straightforward. Just run aspnet_regsql to create a membership database, add the [Authorize] attribute to action methods you want to protect from anonymous users and you are good to go.

And, of course, there’s the backing of everything else in the (ASP).NET framework. The familiar providers, validation, exception handling, configuration files and deployment perks are all there along with several other ‘features’ of MVC I didn’t try but plan to use soon - the ability to write tests against each controller\action pair and partial views, the MVC equivalent of user controls.

Oh, and there’s no view state to double the size of your page to worry about. Did I mention this before? No? OK. No view state.

To MVC or not to MVC?

So would I use MVC again if I had the choice for a commercial application? For the time being, no. Apart from it still being in beta for the time being, I think it’s unfair on the client to produce code which is naively written without some experience to back it up. Unless a job had a very exacting set of instructions \ workflow that meant testing was a pre-requisite, I don’t think I would use it again for another six months until I’ve got more comfortable with it all. The release of the MVC source code on codeplex has meant that debugging problems has produced far more accurate and immediate diagnoses than would otherwise occur (Steve Sanderson details how to hook the source code up to your own efforts here) but despite that, I want to practice with this more and get a grip on things like Html.DropDownList and its SelectList ‘model counterpart’ (my term), [HandleError], partial views, ModelState, the pros and cons of alternate controller classes such as those in MvcContrib and likewise of alternate view engines such as NVelocity and nHaml. And read a few more books of course.

Upgrading to MVC RC1

I was going to write this the day that the RC1 build of ASP.NET MVC was released, so it seemed only natural to postpone that and make a few notes. It would seem that actually upgrading to the RC1 DLL is very straightforward, as are losing the code-behind files for your view classes. However it does appear that several features have been switched on in RC1 that weren’t before. Case in point - input validation (for dangerous values in text such as <html or script tags>) seems to have been switched on. For those curious, the answer is to switch it off at the controller level and not wonder why the site is ignoring web.config. (full details here).

RC1 also includes the MVC dlls for inclusion in your source control tree as bin deployment is still enabled for MVC rather than needing to install it into the GAC as the MVC installer does. It also includes an IIS script to map the .mvc file extension to the aspnet_isapi handler for those IIS6 admins who would rather not use a wildcard script map to allow extension-less URLs to work. Note however that Steve Sanderson and Duncan Smart demonstrated how to add the wildcard script map to an MVC site as a while and then remove it from those directories containing only static content (images, scripts etc) which was the main source of contention in this regard.

Going forward

As you can tell, my opinion of ASP.NET MVC thus far is mixed. I can appreciate its worth but am not so advanced an ASP.NET programmer that I’ve really hit a wall with webforms to hate it. Nor am I previously familiar with the MVC pattern enough to want instantly to use it to the exclusion of all else. I do know that it isn’t going away though and while webforms will continue to be my first choice of templating engine for ASP.NET, it’s only sensible to grok MVC as well. And Dynamic Data too - although that’s for another day.

Comments are closed