Earlier this morning, I commented on twitter that I was starting my 2nd full-fledged ASP.NET MVC project, and was finding myself writing a massive amount of infrastructure code. Ironically, having to write so much infrastructure code was a major complaint I had against both Oxite and Kobe. A number of other twitter-folk replied with similar thoughts. There isn’t a day that passes that I don’t think to myself using ASP.NET MVC is a mistake.
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.
Alternatively, you can leverage some OSS tools, like MvcContrib, FluentNHibernate, xVal, Castle.*, jQuery. While all of those tools are really great, they too lack any cohesiveness. For example, trying to modify the jquery.validate hook from xVal which relied on modified Castle.Validators (to make them work on FluentHTML) was simply too much work for me. I considered using FluentValidation, but the only reference to xVal integration was a blog post.
I’m a huge fan of these tools, but ASP.NET MVC + 7 different OSS projects simply can’t come close to competing with the elegance, ease of use, and completeness of a well-managed and controlled project like Web2Py (for one of the many examples).
There is some good news, and that’s that a lot of this “infrastructure” is reusable, which makes projects like S#arp Architecture possible. However, I’m still sceptical that these projects can truly succeed against better integrated frameworks.
There will be those that defend ASP.NET MVC by saying that it’s still very young. Microsoft only has itself to blame for being so slow and hard-headed for so long. Others will be thankful that ASP.NET MVC is less opinionated, and thus more flexible, than most other MVC stacks. I agree with this, but only because they ought to have an System.Mvc.Core assembly which contains the open-and-flexible frameworks (yet still provide much more than they currently do), as well as a System.Mvc assembly which is much more opinionated and thus provides even greater functionality.
When you look at the popular web frameworks for web 2.0 style sites, ASP.NET MVC and WebForms are backed by the biggest and richest company (by several orders of magnitude) yet remains the least popular. ASP.NET MVC offers less features, requires more knoweldge, and has lower productivity, despite Microsoft having a cafeteria staff that’s probably 10x the size of PHP, Rails and Django’s entire development teams combined. (Even more ironic, www.asp.net is the only major web-framework website to have ads on it…none of the open source websites do…how screwed up is that?)