Monday, April 27, 2009

Is ASP.NET MVC a half-baked solution?


Let's be clear, ASP.NET MVC is an improvement over WebForms - and those developers refusing to leverage ASP.NET MVC (or something else) for new projects are simply lazy. WebForms is full of leaky abstraction, really tight coupling, and ridiculous concepts - such as viewstates and postbacks.

Being able to write complex systems more cleanly is a good start, but given where web development stands in general, and other platforms specifically, ASP.NET MVC lags far behind (Perl being the only one I can think of which is worse).

There's little question that a big part of the problem is that this is really a VC stack - there is no thought, no support, and no tools for the Model. When you compare the thousands of lines you'll end up writing for your repository/dal/linq/nhiberate to other MVC stacks (which commonly only require that your models to inherit from 1 class), you're already at a serious productivity disadvantage. But the true impact is actually much worse - you lose any cohesiveness of purpose through the controller and views. There is no way to generate HTML labels from model properties, or client side validation. In frameworks such as Akelos, RoR or Django everything flows outwards from the model which allows those frameworks to provide cohesive and integrated tools, not just HtmlHelpers, ActionResults and Routing (which is all you get from ASP.NET MVC).

You end up having to do a whole lot of plumbing on both sides of your system.