There’s been a lot bouncing back and forth about whether the ASP.Net MVC (and the MVC manner of building web apps in general) is a good thing or not. I’d propose summing it up in two bullet points:
- CON: The ASP.Net MVC framework *is* half baked. It isn’t usefully opinionated in the slightest other than it more or less promotes the MVC/Model 2 pattern, it encourages way too much sloppy “magic string” antipattern violations, it doesn’t have squat out of the box in terms of the “M” or helpful conventions on par with Rails, nothing like Capistrano (that might be changing soon though), and the Html helper libraries out of the box are just plain weak (I don’t like their approach for the MVC Futures either. It’ll make the MVC more friendly to WebForms folks, but has the exact same problems as the current helpers). In my opinion, the MVC framework is not efficient unless you’re willing to roll up your sleeves and build your own project specific infrastructure to fill in the “M”, achieve some better testability, easier screen synchronization, and more productive Html helpers like what Jimmy Bogard describes here. If the thought of rolling your own NHibernate or “validation framework of your choice” integration with the MVC framework fills you with dread, then I don’t think you’re gonna want to use the MVC — and that isn’t something to be ashamed about.
- PRO: It’s pretty easy and straightforward to take the MVC framework by the horns and customize it for your benefit. Granted, I felt like we hit a wall with the MVC framework at Dovetail and moved on to the FubuMVC efforts, but many of the things we’ve done that have enabled the most productivity for us are perfectly applicable to the MVC framework out of the box.* I think that a lightweight application framework that’s specific to the application being built will almost always be more productive than a big, giant heavyweight “one size fits all” generic framework.
To sum it up, I think the MVC (and any MVC framework for that matter) framework is a tool that maximizes the effectiveness of development teams that are willing and able to use creative solutions, but at this time doesn’t do much to help average teams who only code with what comes out of the box. I’d also say that the “To MVC or not to MVC” argument is a classic example of the “Safety versus Power” argument. I stand behind the assertion that the ASP.Net MVC framework is a better way in the end to build web apps than an “abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand,” but at this point it’s probably a tool strictly for early adopter type folks.
Oh, and I don’t really want Microsoft to be the ones creating the more robust, opinionated stacks on top of the MVC framework anyway. I’d much rather see the community build the specific integrations and application stacks because we have more freedom to choose tooling than an internal Microsoft effort, and some level of diversity is a good thing. Microsoft putting out the official, comprehensive MVC solution could easily be a disaster that completely chokes off any further innovation.
* I think we hit the wall with the MVC out of the box mostly because of the Thunderdome Principle and a convention based presentation chooser model for alternative browsers (we swap views and sometimes the presenter and view if the browser is on a mobile device). We also tie the controller registration directly to the route configuration to eliminate errors (another shortcoming of the MVC framework IMHO). At that point we found that the MVC controller lifecycle was simply too limiting for what we were trying to do and frankly wasn’t that hard to completely replace.
