To MVC or to WebForms?

In case you haven’t been following it, there’s a sort of blog storm happening around whether or not you should learn ASP.NET MVC (or indeed MVC in general) or stick with Web Forms.

You can follow the storm here:

Ok, so now that you’re caught up, I’d like to try to sum up this whole argument with this piece of advice:

Productive Bliss: If you’re happy with WebForms, and feel that it’s delivering you good value and you’re not sure what this “pain” or “friction” is that everyone keeps talking about, then you definitely should stay on Web Forms.

Disappointed Disillusionment: If you generally like WebForms, but you keep bumping into problems (long postbacks, viewstate continually causing issues for you, hard to test, etc, etc), then you should start looking into the MVC pattern in general, and maybe start dipping your toe in some of the content over at

Disenfranchised Frustration: Let’s say you came to ASP.NET from PHP, Java, ColdFusion, or some other framework and you like ASP.NET, but you can’t believe how ridiculously hard some tasks are compared to PHP, CF, or some other framework you used.  You like .NET and don’t want to go back, but insist there must be a better way, definitely go check out ASP.NET MVC right now.

Diabolical Disgust:  If you’re appalled at how tightly coupled, SOLID-violating, and horribly mis-abstracted ASP.NET WebForms is, not to mention how completely impossible it is to write testable code, then you might think about skipping both ASP.NET Web Forms and ASP.NET MVC, going straight to something further like OpenRASTA or even FubuMVC (if you dare).

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in ASP.NET, ASP.NET MVC, FubuMVC. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Chad – I think you are much more succinct and persuasive in your points than either Rob or I. Personally, I think that people should learn MVC regardless of whether they like WebForms or not. You can’t make an informed choice until you become informed.

  • @Joe, quick question: If WebForms is great for you, and you know it and feel it, why bother learning ASP.MVC? True, it’s still a useful pattern to know, and some frameworks do it quite well, but if WebForms are enough, then is learning ASP.MVC really worth your time? And finally, if you know WebForms very well, and know you do not need anything else, is that not an informed decision? Maybe not an informed decision, but perhaps quite pragmatic. ;)

  • @Kyle, I think the idea of ever “knowing you do not need anything else” is pure fallacy.

    Its basically equivalent to the blub paradox, as described here:

  • @Paul, you may think that, but you’re wrong. I know I don’t want to smoke cigarettes even though I’ve never done it. I even know I don’t want to do anything of the kind without having done it. I know I don’t need anything other than being clean and healthy. I’m also hoping I am not equivocating here, nor twisting your words. I apologize if I am – I just don’t think what I said was fallacious: I think it’s not only possible, but quite probable that there exists someone who 1) knows they don’t need anything other than WebForms, 2) has a good handle on WebForms, and 3) really doesn’t need anything better than WebForms objectively, and so is making the right choice by going with it.

    I happen to disagree with Mr. Graham in that post on at least one point: Machine language is the most powerful programming language available. It’s just the least practical and the hardest to program with (in my opinion). However, if you were to master it, you would have every possibility that you could have with any programming language.

    Incidentally, I think Lisp is awesome, and the rest of that article is very good. :) I like Paul Graham – he’s got a good, practical head on his shoulders.

  • Darn. Nope, you’re right, Paul. My argument is an argument from ignorance – just took me the train trip to realize why my counter-argument is also fallacious. I already KNOW that smoking is very bad for me, i.e. I am informed in my decision not to, even if I haven’t experienced it directly. And even if such a hypothesized person existed, that person still wouldn’t be justified in their claim that they know they don’t need better, or anything else.

    Sorry about that, Paul. I rescind my statements. You were right.

  • Chad,

    You do a great job of distilling it. FWIW, my opinion (as an non-ALT.NETter) is that it’s a toolkit that I want in my belt. Those I mentor I’ll be telling them to try it, and learn about it because pragmatically speaking it may be a better course of action (depending on your project)..

    I’m currently porting an old-school JSP app (not using an MVC framework, but very MVC-like.. all business logic is in java classes) to ASP.NET MVC, primarily because it’s just a lot easier to do that then it would be to rewrite everything in ASP.NET WebForms… the porting story is a lot better…

  • WebForms tries to “abstract” the http protocol…it’s like trying to abstract chicken noodle soup by making you drink it from a super soaker riding in the side-car of a motorcycle. Chicken Soup is simple, why make it ridiculous? While asp.NET MVC isn’t my favorite web stack, at least it doesn’t put my soup in a water gun. I’ll have to check out fubumvc a bit more.

  • @Kyle, Great! As for the power argument, it seems its might be difficult to come to a consensus on what the most “powerful” language is, but surely you would agree that machine code rates very poorly when it comes to -expressive- power in particular.

  • Move over ASP.NET WebForms and MVC…

  • @Paul, I certainly agree, there. The first thing I think of when I see power, though, is just what can you do with it at all. But your point still stands, too.

  • DP

    Nicely done.


    Disenfranchised Frustration:
    this is soo me! however, It reassures me to know I am not alone in that situation… I didn’t have choice to embark on the boat, and being a php guy I can’t help but think of the webform as such a heavy, far from being optimized code.

  • jiang

    WebForms is not perfect, but it works. Efforts can be put into making webforms better and more testable, etc. It can be done instead of reinventing the MVC wheels over again. WebForms is uniquely Microsoft’s invention and it’s a higher level of abstraction. Leaky? Every abstraction leaks as long as it is an abstraction. If you don’t have the brain to make WebForms work for you, then you don’t have the brain to be a programmer of any pay-grade. Deal with it.

  • @jiang Is your employer aware that you spend a lot of time feeding the web forms beast instead of writing useful functionality?

    My employer would be upset to learn that I was spending extra time trying to make WebForms testable rather than writing functionality, but maybe yours is more willing to be throwing money away than mine is.

  • @jang

    Anyone who says
    Every abstraction leaks as long as it is an abstraction.

    doesn’t deserve to be a programmer at any paygrade.

    Comments like that are a disgrace to good developers everywhere. Shame on you.

  • @jang Furthermore, the whole point of abstractions is to hide complexity, not generate more.

    If you’ve ever had to move something to OnLoad instead of in a ctor because ViewState wasn’t populated, or move something to PreRender because ChildControls wasn’t populated yet, you’ve dealt with the fact that the abstraction is more complex than the thing it intended to hide.

  • Francis

    Chad and others,

    It’s clear that this post and many of these comments are fueled by your arrogance, ignorance and inexperience.

    If you had been around as long as I have you would know that ASP.NET MVC is just a fad that many people are hopping on because all the “cool kids” are doing it. Meanwhile, the rest of us are producing quality software at a significantly faster pace.

    ASP.NET MVC is just a slight rehash of Classic ASP. Classic ASP had it’s problems then and ASP.NET MVC has it’s problems now. For one, both things are leaky abstractions. They do a poor job of abstracting the way that we think about UI and the way that win forms does UI. If a control (like a text box) cannot remember that it is supposed to be blue after someone clicks a button, who will? Storing it in the database is just crazy. If you had enough experience you would realize that ViewState and ControlState are NECESSARY. It is a limitation of the internet that they must be created, but without them web pages must rely on hacks to provide real functionality.

    Another big issue for me is that ASP.NET MVC does not allow you the same flexibility that webforms does. For example, in WebForms you have the flexibility to inject code in so many places. You can choose to do things before or after the page is initialized, before or after it’s loaded, before or after it’s rendered, after it’s unloaded, etc. With MVC you can do what, stuff before an action or after? Come on. It doesn’t take a rocket scientist to see the flexibility and power that webforms affords you.

    Another glaring issue is code reuse. With MVC there is soooo much stuff I need to do in order to reuse a page in another project. Even Classic ASP got this better. With Classic ASP I could just copy an asp file from one directory to another and change the connection string or maybe the table names. That was it! Easy! It’s a bit harder with webforms, but if you do everything right (use datasources, databinding, etc) then you usually only have to copy the aspx and the aspx.cs page. Also very easy. This is great because it allows really good collaboration between friends on their projects.

    I really feel like I should come out of the shadows and start a blog so that I can try to fight off this FUD/misinformation that is being spewed from the “ALT.NET” crowd.

  • Francis,

    Your ability to jam-pack so much ignorance in a single blog comment is astounding. You should definitely start a blog. Come out of the shadows and save the world from the MVC beast!

  • @ Francis Sorry, you don’t get a free pass on calling people inexperienced and arrogant, then post that. The leaders in the Alt.Net crowd’s experience is very well documented. Can’t say the same for you…

    Your comment makes my point further, and goes to Jeremy’s “Lie Sauce” idea.

    “You can choose to do things before or after the page is initialized, before or after it’s loaded, before or after it’s rendered, after it’s unloaded, etc.”

    What does “initialized” mean? How is that different from “Loaded”? What does “Unloaded” mean?

    For the record, I know the answers to these, and understand Asp.Net webforms lifecycle quite well. The point is, understanding this does NOTHING for functionality in an app. Understanding it is a necessity to using the abstraction that is webforms. An abstraction that is more complicated that what it intended to hide.

    You say it’s “NECESSARY”, but haven’t proved it, the only reason it’s “NECESSARY” is because MS made it so with the pointless abstraction of HTTP POSTS and GETS.

    “With Classic ASP I could just copy an asp file from one directory to another and change the connection string or maybe the table names. ”

    This comment is a demonstration of your lack of understanding of the fundamentals of good design principles, I probably wouldn’t have said that in the same post that you called others inexperienced.

    Best of luck though!

  • Peter

    Francis, please note that Chad’s been very nice and accommodating in this post, so I think you’re venting general frustrations, not aiming at Chad. In his post, he didn’t even say WebForms is bad, instead just noting that some people are frustrated by it.

    At this point I’m suspicious “Francis” is a troll, that comment is too perfect.

  • I predict we never see Francis’ blog. Maybe we just won’t recognize it since he has no last name. I’ll be scanning the Web for “47 Places In The WebForms Lifecycle You Can Inject Code” or “Making The Web Stateful In 5Mb Of Viewstate Or Less” by Francis.

  • Francis,
    To MVC, or not to MVC: that is the question:
    Whether ’tis nobler in the mind to suffer
    The slings and arrows of outrageous Webforms,
    Or to take arms against a sea of lambdas,
    And by opposing end them? To code: to MVC;
    No more; and by MVC to say we end
    The heart-ache and the thousand natural shocks
    That WebForms is heir to, ’tis a consummation
    Devoutly to be wish’d.

  • Is Francis a troll? Or the last hope for the mort webforms developers out there?????

    I agree with Peter, Francis’ comment is too perfectly full of mistakes and ignorance enough to make it suspect of “machine generated” :P

  • Andrew

    It’s easy to beat up on a post like Francis’s, but unfortunately (assuming this isn’t a well crafted troll post), this is the way a lot of people think in the corporate world.

    Since ASP.NET MVC is new, plenty of people assume that MVC is new and hence a “fad” (something I’ve read multiple times in multiple places not just this one post). Obviously that is not the case, but for enough people out there, perception is reality.

  • We have pretty testable code where I work now the downside is that our non UI code needs to many separate layers. To make all code completely testable we have what we call a Control/Controller layaer on top of a business layer. The control/controller pair is testable and a unit or they can be testet individually. The downside is more code has to be written compared to a more standard MVC or MVP pattern.

  • Generic Viagra

    We are quite testable code where I work now the problem is that our interface code does not require many different layers. For all the code completely verifiable, we have what we call a spade control / driver in the top of the business layer. The couple in the control unit / command and is testable or can be tested separately. The disadvantage is more code to write more than one standard or MVC MVP.