404 Should You Use ASP.NET MVC? | Kevin William Pang

Should You Use ASP.NET MVC?

There are a lot of ASP.NET web forms developers out there who admit that they simply don't "get it" when it comes to all the hubbub surrounding ASP.NET MVC.  In some ways, I can sympathize with them.  The vocal minority that raves about ASP.NET MVC gush about it with such zeal that they make it sound like you'd have to be a fool not to switch over.  In actuality, the decision isn't nearly as black and white. 

ASP.NET web forms aren't going anywhere.  As much as I love ASP.NET MVC, it is not the end-all-be-all one-size-fits-all solution to web development.  Both of these approaches have their rightful place in a web developer's toolbox and it's important to recognize their strengths and weaknesses.  In general, the ASP.NET MVC framework tends to sacrafice ease-of-use (e.g. viewstate, validation, etc.) in order give developers tighter control over the reins.  This can be a great thing, but only if you take advantage of it.  Otherwise it can just as easily be a hindrance.

With that in mind, I have developed a quick metric to determine if ASP.NET MVC is right for you.  The way I see it, there are three primary reasons a developer should choose the ASP.NET MVC framework over ASP.NET web forms.  If none of these reasons are compelling to you, then you should stick with ASP.NET web forms:

To Unit Test

This, in my opinion, is the most compelling reason to use ASP.NET MVC.  When it comes to unit testing, ASP.NET MVC simply blows ASP.NET web forms out of the water.  It's not even close.  Whereas ASP.NET web forms requires you to jump through all sorts of hoops to test around the page event lifecycle, the ASP.NET MVC framework practically begs to be tested.  There are interfaces everywhere screaming "mock me!". 

There's a reason why the biggest ASP.NET MVC supporters also tend to be TDD proponents; it's because ASP.NET MVC actually allows for TDD.  Personally, I think this is where all the zeal comes from.  Simply put: it's really, really hard to do TDD with ASP.NET web forms and really, really easy to do it in ASP.NET MVC.

To Gain Control and Extensibility

As pointed out in the comments, ASP.NET MVC gives you more control and extensibility options than ASP.NET web forms.  You get complete control over the page request lifecycle and the ability to substitute out several key pieces of the framework (e.g. view engine, routing, etc.), none of which is possible with ASP.NET web forms. 

In addition to this, you also gain full control over the rendered HTML.  In general, the rendered HTML from ASP.NET web forms applications is atrocious.  The web controls it utilizes generate garbage ids and hidden fields galore that not only hamper the performance of a site, but also make CSS styling and Javascript development a pain.  ASP.NET MVC forces you to be more in tune with your HTML.  There aren't any repeaters or datagrids that magically generate markup for you.  There aren't any hidden fields to persist state for you.  It's just you, the HTML, and a few extension methods (which you don't even have to use).

To Learn Something New

In other words, "because you feel like it".  This was actually why I started using ASP.NET MVC.  It never hurts to look at how you're approaching development from another angle. 

I should also point out that learning ASP.NET MVC is incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process.  I think a large part of the appeal of ASP.NET MVC is that the community's input is not only being taken into consideration, it is actively being sought after.  The framework has sparked so many discussions and debates over best practices that simply following along introduces you to concepts you might previously have been unaware of.  I would actually recommend learning the ASP.NET MVC framework for this reason alone.  The threads on TDD, BDD, ORM, AJAX, etc. you stumble across during the learning process are worth it.

So there you have it.  Aside from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC.  Maybe this is why the adoption rate isn't nearly as high as we think it should be.  The incentive for using the framework essentially boils down to unit testing, control/extensibility, and boredom/curiosity.  Good reasons, to be sure, but hardly game breakers for the vast majority of developers out there.

What do you think?  I'm interested in seeing if anyone can come up with another reason(s) that I may have missed here.  Why do you use ASP.NET MVC?


Kevin Pang

Kevin is a software engineer at Google whose programming interests revolve around web development, software architecture, and design. When he's not writing software, he enjoys watching Jeopardy!, playing Magic the Gathering, and wandering around Disneyland.


25 thoughts on “Should You Use ASP.NET MVC?

  1. Not just control over the generated markup, but control over the entire request lifecycle.

    I think the other thing people would argue is a big benefit of ASP.NET MVC is the extensibility possibilities. Don’t like the view engine? Swap it out. Don’t like routing? Swap it out. And so on.

  2. Thought I should also mention that you don’t lose webforms when you use MVC, they just aren’t adding automatically. One website/project can use both.

    No sense throwing out that shiny glowy grid control your company spent hundreds of man hours creating.

  3. @John Farrell

    Very true. There’s definitely enough room for both. I believe Scott Hanselman has a blog post demonstrating how the two can coexist in the same project.

  4. I am [i]really[/i] new to ASP.NET MVC.. I’ve been doing WebForms for a couple of years now and I tell you what working with MVC has been a real pleasure/pain experience..

    I’ve also been getting in to TDD, which MVC is fantastic for. As covered already, everything is malleable in MVC.

    MVC seems a hell of a lot faster.. There has been a noticable performance increase (or at least perceived to be one) in both build times and well as running.

    Simply put, I like the pattern. Seperation of concerns is a good thing! It helps me write better code, period.

    TBH, not much here but I wanted to write some code to solve a common problem (adding version number to CSS [b]without SVN[/b]. Now, in WebForms this would have been a piece of cake. New UserControl, override render, do your magic to find file version, render it..

    [i]However[/i] in MVC I have found this to be a real challenge thus far (about 4 hours and counting!).. The concerns are so seperated me and my noob brain are struggling to see where you put small pieces of model/view.. Still working on it now and hope to be blogging my final code very soon..

    I think it will help once we have more learning material out there and these kinds of problems are run in to by more people..

    That said, I actually feel in my gut that this is a good thing.. Been a while since I truly felt that about new stuff in ASP.NET! We now have a great framework and a vastly improved engine to lay over the top of it!

  5. "Aside from that, I can’t think of any other reasons…"

    I’d say those 3 were pretty darn good, and sufficient enough for me to want to use MVC in most cases.

  6. Good points. I used to love developing in .NET with webforms until I started working on some PHP projects. Then I realized that webforms are just a pain for the type of sites I create. They do have their place though. I enjoy ASP .NET MVC because as John pointed out I get control over the entire request lifecycle.

  7. [quote]There aren’t any repeaters or datagrids that magically generate markup for you.[/quote]

    This pretty much sums it up. Everytime I try to customize an asp.net control I consider starting over and writing the control from scratch.

  8. @mgrooves, Tim Erfle

    I think the phrase "different strokes for different folks" applies here. That is, ASP.NET MVC is great if you care about the benefits it gives you. If you don’t, then you’re not going to see much, if any, benefit in it.

    For you (and me as well), the three reasons listed above are compelling enough to make the transition worthwhile. Whether or not other devs see it that way remains to be seen. Regardless, I think it’s a pretty good metric to judge whether a developer should care about ASP.NET MVC or not.

  9. Not to sound super-abstract architect astronaut but I think it might be easier to answer…

    Should you NOT use ASP.NET MVC?

    I think though the page life cycle might not hold state but I think ASP.NET MVC brings back web development to traditional developers who are used to dealing with classes, not controls. I believe ASP.NET MVC is a developers web framework.

  10. Another point that would be useful is the use of convention to organize and clarify. If you know MVC for web, then you can find where things are much easier than a typical asp.net app; which could have code and configs anywhere.

  11. It’s simply brilliant compared to ASP.NET webforms. I’m developing a huge online service atm, and working with MVC makes all the HTML/design aspect a walk in the park. Integrating with jquery and full control over all ids and control-names, no stinking tables getting generated by datagrids and so on. On the "code-behind" part, using strongly typed viewmodels to pass into the views, and filling them using Actionfilters is a joy, and I never find my self in the "Where should I debug in order to fix this"-situation I’ve been in several web-forms projects.

    MVC makes my day much more enjoyable.
    So, to answer your question. YES, i use ASP.NET MVC, and I’m lovin it :D

  12. Great write up… coming from a strictly web forms background myself I totally see your points. The number one reason I enjoy MVC is the simplicity and pure control over markup. I do however still feel that web forms have their place in the development world.

  13. I disagree with this whole "…its good if you want control of the markup" argument.

    WebForms was designed so that you could develop web applications and not understand how web programming works. It did a decent job in some areas, and a terrible one in others. As long as you actually do understand how the web works, and learn the rediculesly complex way that webforms works, you can usually work around the profoundly bad ideas yourself (ViewState, ASP.NET AJAX, the raping of element IDs, Extenders). The problem with WebForms is while they will take you 80% of the way extraordinarily fast, that last 20% will take about ten times as long as it should.

    The MVC model is the direction everyone else outside of microsoft moved to years ago. It fits the web a lot better, reduces the complexity and overhead of ASP.net, and using it will not get you painted into a corner of pain the same way that webforms almost inevitably does. The one and only downside over webformss is you can’t do anything without actually understanding and learning the technologies that power the web.

  14. Could someone explain what exactly you are able to test that you couldnt test in webforms? I mean most of the business logic, data access are factored out of webforms and can and should be tested outside of a web context.

    Are you testing the html response based on a simulated request to the controller? This sounds more like the ability to write acceptance level tests than unit tests. Please be gentle and fill in the gap in my understanding of MVC.

  15. @mike johnson

    With ASP.NET MVC, you gain the ability to test your controller actions, which are analogous to the server side events in ASP.NET web forms. For example, a unit tests that you can do easily on ASP.NET MVC but not in ASP.NET web forms is testing whether or not a user is redirected to the correct page when they click on a link. This will let you test, among other things, if your security settings and permissions are working as expected.

    You can also test out behavior this way (i.e. when this action is performed, are the following functions called and is the response to the user what you expect).

    You aren’t necessarily testing the html response so much as the system’s response to requests to the controller.

  16. @kevin

    thanks for the explanation. I can definitely see benefits of being able to test more in the base tool (vs 2008) compared to what we have done at the shop I work for in winforms and webforms.

  17. @crag

    To test the UI we have been using ACT to record and execute scripts for years and unit tests for things CRUD logic that was incorporated into the page. Is it perfect? Definitely not. The UI scripts are not as sensitive as scripted testing in the desktop days with VT but you still get days of "fail 500".

    I asked my question because TDD is almost always held up as the #1 gain in coding for asp.net MVC and I wanted to know what is gained because I sensed there is a gap between what I perceived to be web testing and what everyone was so excited about.

  18. [i]There aren’t any repeaters or datagrids that magically generate markup for you. [/i]

    I know what you mean (we do not employ people who show a tendency towards auto-generated HTML), but repeaters and placeholders are the only ASP.NET controls I use as they are the only ones that don’t "magically generate markup". Repeaters give you complete control over what HTML is output (Datagrids and Datalists are horrible though).

  19. @John Farrell, @Phil Betjeman

    When I first saw MVC there were two negatives. One was the ugly classic ASP if statements. The Second was no controls which I thought ment no generic Grids.

    With new technology comes new ways of thinking. What ever control you lost look to JQuery plugins to replace it. DataTable, jqGrid plugins are replacements for the grid control. jVal and Validate are plugins that replace the Microsoft validation.

    As far as old classic ASP look I have found ways to maintain a clean look. DropDowns require a for-each loop to spell out all the options. This can add alot of code to page. So refactor and put dropdown code into a partical. Then on the main page do a RenderPartical.

Comments are closed.