My Quick Oversimplified ASP.Net MVC Pros and Cons

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:

  1. 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.
  2. 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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jason

    MVC sucks more than anything when trying to integrate into a WebForms application. There is some very cool open source stuff coming out built with MVC and it is nearly impossible to use it with an existing codebase.

    @John, granted ASP.NET WebForm controls spit out html that you don’t see when you drag the control into your page, but big deal, all you have to do is look at the source and go oh, so that’s what it’s doing.

    I come from a background in web development and Windows Development so it’s nice to not have to worry about the html sometimes and the times I do need to worry about it, its not hard at all to work with what the ASP.NET controls spit out. However if you throw MVC into the mix you have a complex pattern to figure out that is nothing like either a web or Windows approach.

    I can handle seperating concerns on my own thank you very much, and I don’t want to deal with the cluster*#@^ roundabout pattern MVC uses. Who knows, maybe after reading a few books on MVC and a couple of months of experimental development with it my opinion may change, but seriously, who has that kind of time?

  • http://bengillis.wordpress.com/ Ben Gillis

    per comments above:

    > WebForms
    It was the *intention* of Microsoft to make it easy to go to the web with non-web developers. Msft targeted a ‘transition generation’ of devs from pre-web to web-based development. WebForms was probably the best move msft made to enable/inspire client-side alternatives! I moved to server-side wrt to asp.net, getting dragged into client-side asp.net dragging my feet (or hiring a client-side guy to just deal with it. And, you’re right, finding a “real web dev” to do that was an issue; w/o non-asp.net skills they were so lightweight I was constantly looking over shoulders (not my hires) hand-holding a number of them. With Asp.Net MVC out, yes, even half-baked, it’s waaaaay better than what they had. As for the M, there are plenty of ORM options and advanced devs should have their own (I can’t remember the last time I hand-coded DB I/O, another story rooted in msft DB I/O strategy…I’m glad they left the M out).

    > CIO or not.
    Perhaps the scattered-brain projects w/o direction should consider taking lessons from those that are not. Top-down CIO w/ Msft gave us 10 years of COM, while peer-to-peer loosely-coupled cfg-able stacks were already established in a number of markets/verticals. And, there’s more, once recent example being the Linq-to-SQL/EF debacle. Grassroots innovation is best, it needs org skills, too.

    > how do we ever get these business’ we complain about to change their perspectives about quality vs. quantity?
    innovative methodology. And, you won’t find it in books. (Once you do, you’re competing against that).
    there are other ways, that’s a book.

  • http://bengillis.wordpress.com/ Ben Gillis

    per comments above:

    > WebForms
    It was the *intention* of Microsoft to make it easy to go to the web with non-web developers. Msft targeted a ‘transition generation’ of devs from pre-web to web-based development. WebForms was probably the best move msft made to enable/inspire client-side alternatives! I moved to server-side wrt to asp.net, getting dragged into client-side asp.net dragging my feet (or hiring a client-side guy to just deal with it. And, you’re right, finding a “real web dev” to do that was an issue; w/o non-asp.net skills they were so lightweight I was constantly looking over shoulders (not my hires) hand-holding a number of them. With Asp.Net MVC out, yes, even half-baked, it’s waaaaay better than what they had. As for the M, there are plenty of ORM options and advanced devs should have their own (I can’t remember the last time I hand-coded DB I/O, another story rooted in msft DB I/O strategy…I’m glad they left the M out).

    > CIO or not.
    Perhaps the scattered-brain projects w/o direction should consider taking lessons from those that are not. Top-down CIO w/ Msft gave us 10 years of COM, while peer-to-peer loosely-coupled cfg-able stacks were already established in a number of markets/verticals. And, there’s more, once recent example being the Linq-to-SQL/EF debacle. Grassroots innovation is best, it needs org skills, too.

    > how do we ever get these business’ we complain about to change their perspectives about quality vs. quantity?
    innovative methodology. And, you won’t find it in books. (Once you do, you’re competing against that).
    there are other ways, that’s a book.

  • http://jonathan-oliver.blogspot.com/2009/04/move-over-aspnet-webforms-and-mvc.html Jonathan

    Move Over ASP.NET WebForms and MVC…

  • mwardm

    Sharp Architecture? [Not affiliated...]
    http://code.google.com/p/sharp-architecture/

  • Brian

    @John

    I’m in the same situation and I fully agree with your cons, but I have to expand on your pros/cons -> to the business who is looking for contract work, you can get some very cheap web developers using web forms for the exact reason you mention – you don’t have to know squat.

    Now some business’ I know would say ‘I don’t care, as long as the product is delivered’. Other business’ I know (a much smaller group) would be concerned about this, but in the end would still not really care as long as the product is delivered.

    So if all of us who realize these things are contractors who get up and leave, how do we ever get these business’ we complain about to change their perspectives about quality vs. quantity?

  • Brian

    I’ve been working in PHP a lot lately and I think the argument of letting Microsoft or letting the community take the lead is a loaded gun.

    The PHP has been fun because there are lot of motivated people doing a lot of cool stuff. But it has been equally frustrating for the exact same reason; there’s no central source say ‘here’s the direction we’re taking’, we recommend this, stay away from this – it’s going away – so often you’re left making decisions that are based upon the opinions of the people in your circle which very circle to circle.

    So to me it falls back to – are you the type of person who thinks your company would be more efficient without a CIO and letting the people in the trenches make the decision or do you think it best to have a chain of command to set a direction? More than likely your answer there reflects whether you are pro-Microsoft (in favor of a CIO and chain of command) or anti-Microsoft (in favor of the people in the trenches somehow coming to a consensus and setting the direction).

  • huey

    I like that the M is left alone but feel torn about MS filling the void. As a solo developer I can pick and choose whatever I want right now and its great. I just worry (and maybe I shouldn’t care) that the person that ultimately replaces me when I leave is going to be screwed by my decisions. If instead I picked an MS sanctioned ‘M’ I would probably be less happy but there is a better chance the next developer could follow my code.

  • John Batte

    First of all, thanks for the post. I enjoyed reading it. Just a couple of long-winded comments though:
    I have a few doubts about just how much experimentation took place before your final analysis. I’ve been working with the Mvc bits ever since Gu posted them for the first time, and I’ve experienced very little pain as a result. The framework is modular, extremely well encapsulated, facilitates a clean & terse coding pattern, and provides the necessary extensibility to enable very extreme customizations. All while allowing the developer to actually learn his/her trade… which can be very disorienting at first, depending on your background: “What’s this Html stuff doing here? Isn’t every tag supposed to start with ‘asp:’? Where are all of my unnecessary abstractions? What do you mean, I’ve been living a lie? What’s this jQuery crap? What do you mean, I’m supposed to process page behavior on the client? What the heck is a client? Where’s my big ball of spaghetti, er, codebehind? But I don’t WANNA learn about the Web! Can’t you just go back to hiding the truth from me? I wanna be put back in the Matrix!”
    I used to be a WebForms guy for years, which is why I can say two things with confidence: One, being a WebForms guy is mutually exclusive with being a Web Developer; and two, I’m never going back. The rest of the web development community (ruby, python, perl, php, take your pick) has known this little fact about us .Net guys for quite some time. Did you know that in WebForms, unless you’re writing Http module code, you’re about 30 frames deep into the call stack when your first line of code gets executed? Seem a little unnecessary for “Hello World” to anybody else? Uh-huh. Thought so.
    Here, let’s do a comparative (albeit biased as can be) analysis of the WebForms pros and cons:
    Pro: You don’t have to know the first thing about the Web. In fact, the further you go down this rabbit hole, the less you will know. You’ll really be able to push your abomination to prod with the quickness though. (Btw, if that’s really a ‘pro’ to you, read no further. You’re not gonna like the next bit.)
    Con: Well… see above. The abstraction über-stack plus a bunch of false paradigms are going to cripple you as a developer. You no longer have one iota of control over the rendered markup (yes, this is still important even though Grandma has broadband now). Nor would you recognize anything if you viewed your page’s source at the browser. Basically, you’ve been “enabled” by M$ into career anemia.
    Sorry if I’m a little blunt about the cons, but my experiences led me down what I believe is a very logical path of “evolution” and this is where I arrived. Asp needed some things. It needed .Net in a bad way. But what they came up with is a slight against the development community, and belongs in history books, not our web servers. Mvc gets us away from the lie, and allows us to do our jobs without getting in our way, FINALLY.

  • http://www.trimediatlantic.com Adam Greene

    Routing is hard coded? Not really, if you look at the code, you will see that MapRoute is simply an extension method that adds a RouteHandler to the routing engine. So if you want a different routing resolution / add custom variables to the RouteValues, then write a new RouteHandler.

    Though with your particular example, it think you will also need to create a custom controller factory that understands the different names for a controller, and then create a base class for your controllers (or use IoC) to assign a different ActionInvoker to ActionInovker property that understands (probably through the use of attributes on the action methods) what the different names for an action are.

  • http://codeclimber.net.nz Simone

    @Dave:
    if you want your controller class to be named Usager you just have to make your own ControllerFactory and tell ASP.NET MVC to use your own one instead of the default one.

    The only thing the routing does is translate URLs to a dictionary of values. It doesn’t do the URL to code translation

  • http://www.sideline.ca Mike

    “…I don’t really want Microsoft to be the ones creating the more robust, opinionated stacks on top of the MVC framework…”

    I think MS has to be the one building these stacks only because they haven’t shown an ability to play nice in the sandbox in the past. i.e. I wouldn’t be surprised if they changed the framework and sent those robust, opinionated stacks tumbling to the ground.

    Now, if they could actually reach out to the community (and I think ScottGu has both the desire and the ability to do this) and work with the community to help those stacks grow and transition, then I think there is the beginning of an exciting and strong community.

    I’ll believe it when I see it. ‘Til then, I’ll stick with RoR.

  • Dave

    My biggest con: The routing module is hardcoded into MVC. It’s not possible to plugin another routing module. Because of that localization is not possible. If I’m naming my controllers using the Englisg language that I’m FORCED to use english paths. Because it’s not possible to route ‘gebruiker’ (Dutch), ‘Anwender’ (German) or ‘usager’ (French) if your controller is named UserController. Same applies to naming the action.

    So, the asp.net MVC framework is only usefull if you’re writing a english based website or I have have to implement presentation into my business code.. and the main selling point of MVC is clear seperation of presentation and code. I think that url’s are part of that presentation. Localized url’s are important for SEO purposes.

    All of these issue are fixable by adding a new interface which System.Web.Routing has to implement. That makes it possible to use another routing module and to translate paths to code (controller/action). The routing part is also the only thing that’s not flexible..

  • http://codeclimber.net.nz Simone

    “Microsoft putting out the official, comprehensive MVC solution could easily be a disaster that completely chokes off any further innovation.”

    That’s the best explanation of why I don’t like the M inside ASP.NET MVC.