On ASP.NET MVC and the other 80/20 problem

Whoever designed ASP.NET 3.5 MVC is a huge fan of Rails.

If you read one sentence of this post, that’s the one; you can stop reading now, most of the article is done. From that phrase, you can infer most of the sentiments I am about to force upon you, the reader: ASP.NET just got a lot less mangled, MVC is winning the day, pre-enforced design patterns are good, and ASP.NET developers should be very, very happy.

ASP classic was just that: Microsoft’s classic web development framework, laden with inline code, no templates, and terrible design practices, not to mention a general development model that most of the company’s previous platform developers had no grasp or bearing upon. Sensing that ASP classic could only ever play second fiddle to the all-too-similar PHP, and hoping to rope more of its existing developers into the whole web thing, ASP.NET was born. In a move that made sense at the time given the above conditions, ASP.NET was sculpted to resemble Visual Basic’s model as closely as possible: Interfaces are designed, then wired with events which are fired, with most of the heavy lifting being done in a code-behind file. Nifty bits and pieces came together like the use of controls and postbacks.

Unfortunately, the web isn’t built like a desktop application, and ASP.NET is often needlessly complex and piggish to compensate – it spits out often unintelligible markup which the developer has little control over, and ViewState data rides down and back between the server to manage page status, a costly bit of bandwidth depletion which is often abused, resulting in ghastly results. It is altogether far too easy to write terrible code in ASP.NET, with ill-defined design patterns. Learning the intricacies, idiosyncrasies, and idiocies of the ASP.NET web framework is a lengthy task, to the extent that being able to accurately spill its guts is a rare quality in a developer.

ASP.NET MVC futures represents a step back from that overreaction Microsoft had so many years ago. Markup you write is passed straight through. Everything is properly wired up to post data back in a more traditional web format. This should hopefully lead to cleaner, easier to manage applications than the behemoths ASP.NET 2.0 tended to create. However, even more interesting is a strange resemblance to many of Ruby on Rails’ structures – routes are declared and processed in a nearly identical fashion, and helper methods and classes are used to aide in template processing, not to mention an uncanny resemblance in directory structure all add up to a tribute to the beauty and simplicity of Ruby on Rails. These are all good things.

You may be wondering what the justification is for the strange article heading. In exploring the MVC framework, the similarities between its setup and Rails’ structure makes comparing design philosophies of the Rails team and Microsoft very easy — and somewhat enlightening, bringing up the interesting question of an “80/20” type of problem.

ASP.NET is convoluted, yes. It is, however, also extremely flexible. Because it is built on the .NET framework, and because much of the web framework and application’s interals are either exposed or redefinable via the XML web.config settings file, it is possible to strip out nearly anything in ASP.NET and replace it with a custom solution. This design philosophy is still extremely prevalent in ASP.NET MVC in spite of the nailed down design pattern models and more web-friendly development model, and the extreme difference in this regard to Ruby on Rails makes a greater pattern more evident. One example of this is in the handling of route mapping. The following two extracts of code do the same thing in different frameworks:


RouteTable.Routes.Add(new Route
    Url = "[controller]/[action]/[id]",
    Defaults = new { action = "Index", id = (string)null },
    RouteHandler = typeof(MvcRouteHandler)

Ruby on Rails

map.connect ':controller/:action/:id', :controller => 'blog'

It’s immediately evident which one is cleaner. With fewer niggling bits to mess around with, the Rails implementation seems to be the clear winner. It even saves itself an object initialization that ASP.NET puts itself through, though it may be argued that Rails’ performance is middling enough that it’s a nonfactor. Indeed, if we look beyond the mere appearance of each block of code, we find a number of mysterious pieces in the ASP.NET implementation that seem completely superfluous and repetitive: why do we need to specify that the id should be null by default? Why do we have to specify what the type of the Route Handler should be; why can’t ASP.NET assume a default? Why do we even need to instantiate a new object? What is all of this extra work that ASP.NET wants us to do that Rails is perfectly happy inferring?

The answer lies within a phrase heard in showing off the framework:

“In this particular instance we chose convention over configuration…”

This is a telling phrase; an instance of convention over configuration requires an explicit, almost a apologetic explanation! The idea of “configuration over convention” is so completely ingrained into the spirit of the company’s products that a single instance of a design choice to the contrary requires a footnote. To the contrary, Ruby on Rails makes a number of choices for the developer which simplifies and streamlines the development process. However, in doing so, it sacrifices the ability to muck about easily with the internals; it’s not nearly as easy to strip out, say, the Route handler or the HTTPHandler and swap in a custom one that befits your application’s needs.

Who is right? The answer is, as with everything in the computer industry, it depends. Ruby on Rails’ design choices will make life infinitely easier for, say, 80% of developers. However, Microsoft’s offerings will definitely, without modification to the core framework, be customizable and thus useful to all developers on the spectrum. This is, of course, merely a side effect of how large Microsoft has become: it is impossible for the company to ignore any sector of its developer base, no matter how small. Meanwhile, Ruby on Rails (as well as Django and other platforms out there) is able to decide for its developers how development should be done, even if that means alienating a small sector of potential developers, or else forcing them to delve into the codebase of Rails itself.

This is the other 80/20 problem, and how it shapes the development process of various frameworks is both interesting and critical to both platform/framework developers and consumers.

0 Responses to “On ASP.NET MVC and the other 80/20 problem”

Comments are currently closed.