ASP.NET MVC – Is The Grass Really Greener?

iStock_000001889684Medium There are three ways now to write a web site in ASP.NET:

  • Use Classic ASP model with everything in the ASPX file and only use HTML controls without the runat=”server” attribute
  • Use the Web Forms model
  • Use the new ASP.NET MVC model

Each have their own benefits that need to be weighed carefully prior to moving forward with a design.  So what does MVC give us that we didn’t already have in either classic ASP or Web Forms?

ASP Model

The classic ASP model has as its primary benefit the fact that it is a familiar model to most web developers and allows us to write lightweight code.  See my post about why classic web developers have trouble with ASP.NET for a larger discussion on this topic.  Other than it being familiar, you might also use this for a simple web page that doesn’t really do anything (static content) or a “one off” application that has very few pages.  However, we all know that “one off” pages end up being larger applications where an application benefits from a defined architecture.  So the only good reason for using this model would be that it is a lighter-weight model than what we might otherwise have with ASP.NET’s Web Form model.

Web Form Model

The Web Form model’s primary benefit over the other two models is that it allows you to create an application quickly with a semi-predefined architecture.  The downsides are that it tends to have more on the client side than it should and you really have to understand event based programming to get it to do everything you’d want it to do, something traditional web programmers are not familiar with and struggle with when they first meet ASP.NET Web Forms.

To be clear, most of the detractors to the Web Form model can be eliminated if you fully understand how it works.  For example, you could purchase or build an HttpModule that handles state management on the server instead of in a hidden form field, or you could simply turn off state management.

If time to market is your most critical determining factor, ASP.NET will probably still be your choice.


So what does ASP.NET MVC give us that the others don’t?  Primarily it gives us a more granular separation of concerns and eliminates the overhead associated with Web Form controls.  Not that we can’t use them, but we don’t have to use them to take full advantage of the model.

For people coming out of a Java/JSP web development background, ASP.NET MVC is going to look a lot more familiar than either classic ASP or the Web Forms model.

However, for those of us already comfortable with Web Forms development, I’m afraid MVC is going to seem like a step backwards.

This isn’t to say that it shouldn’t be used.  Just that there is a learning curve associated with this new model as there is with any model.

If you need a high performance web site and are willing to put time into learning this new model, ASP.NET MVC might just be for you.

One type of web application that might benefit from this new architecture is one which is primarily AJAX-based using a lot of JSON calls to web services.

That is, because you are avoiding postbacks, you wouldn’t be using Web Form controls anyhow.  In this case, you’d either need to roll your own architecture or you’d want to adopt one that fits what you are doing on your site.  I always opt for using something someone else has created.

If you’ve been using the classic model, you really should drop that and use MVC instead.  Classic is architectureless (is that a word?) and having architecture is always better than no architecture.

Do you really need it?

microsoft has made it pretty clear that ASP.NET MVC isn’t for everyone.  It is a way of programming a web site that has specific benefits to a specific class of programmers and/or organizations.  It is not THE way to program ASP.NET.

My fear for us as programmers is that many lead programmers will convince their organizations to move to this new model simply because it is new and therefore better.  Because they want it on their resume.  Rather than because there is a strong business case for moving to this new architecture.

Be careful to choose the right tool for the job.  Not what you know and certainly not what you want to put on your resume.  Just because it is new, doesn’t mean it is greener.

Other places talking about ASP.NET MVC:

Chapter 4 – Understanding Views – Therefore, if you want to test the views in your ASP.NET MVC application, you must seek an alternative. In this section, we discuss three methods of testing your views that do not depend on the default Web Forms View Engine. …

WebForms or MVC? What about the third option? – The website is so plain simple that ASP.NET MVC would fit just fine. Why botter to coin a new term to develop a site like that. ZeroForms is WebForms, but may have a better performance, as many bloated things of WebForms is …

Less Than Dot – Blog – Learn Visual Studio 2010 now by watching … – We’ll begin seeing how Visual Studio 10 and the .NET Framework 4.0 offer compelling new functionality for web developers. In this episode we’ll be specifically focusing on ASP.NET WebForms 4.0, and what enhancements it offers. … is designed to help you learn how to utilize the Visual Studio 2010 features and a variety of framework technologies including: C# 4.0, Visual Basic 10, F#, Parallel Computing Platform, WCF, WF, WPF, ASP.NET AJAX 4.0, ASP.NET MVC Dynamic Data. …

Is Classic WebForms More Mature Than ASP.NET MVC? : Jeffrey … – In my last post about ASP.NET MVC , Jeff Gonzalez referred to WebForms as “Classic ASP.NET”. I had to take notice since when ASP.NET can out, we spoke about “Classic ASP”. This mere reference is interesting. His comment goes on to talk …

Shawn Wildermuth – Building AgiliTrain: Part 1 – Why ASP.NET MVC – That’s pretty close to my experience. I thrashed for a couple of weeks wondering whether going back to WebForms would be faster…but I was patient. I talk to some people about their fears of ASP.NET MVC and the big one I hear is lost …


Other post in ASP.NET MVC

Related Post

4 Responses to “ASP.NET MVC – Is The Grass Really Greener?”

  • Dave:

    I second your comment about wanting (needing?) to use MVC if you want to do a lot of clientside. I’m writing an app now that makes heavy use of AJAX calls and have basically architected my app to go AROUND Winforms by using generic handlers.

    I suppose there is still a need for traditional WebForm apps, but I’m not seeing it from where I sit. More and more web apps are moving toward AJAX models and I think that unless you are using Flash or Silverlight users are going to expect the type of interactivity you get from libraries like JQuery or ExtJS. And it seemed to me that trying to make that all work properly with Webforms was just one kludge after another. (Trust me, I tried to write my own ExtJs controls and also did a lot of my own code on top of the Coolite extensions and it was a major pain in the butt.)

    I also think that with Ruby on Rails gaining popularity, more devs are being exposed to MVC and the “wonders” of it.

    So I guess my opinion is: if you are a ASP.Net developer you should definitely learn MVC – even if you don’t need it now, you will want it later. And any architect that says you have to throw away your architecture and start over with a “new” technology needs to be shot. :)

  • “My fear for us as programmers is that many lead programmers will convince their organizations to move to this new model simply because it is new and therefore better. Because they want it on their resume. Rather than because there is a strong business case for moving to this new architecture.”

    Well, here’s the thing, it’s not new at all. It’s quite old – it’s a model I was using in about 1999 with Delphi 3.0 and WebBroker, and MVC predates my first experience with it by a 20 years before that. It’s getting us back to where we *were* before WebForms turned up and tried to put a leaky abstraction on what was functioning quite well for most of us. It gets us back to HTTP, to understanding what HTTP as a platform is doing for you, and away from the page lifecyle subtle-bug-that-takes-a-week-to-nail horror, the ViewState weight, the almost-events-but-not-quite-isn’t-this-similar-to-Winforms-you-lost-looking-VB-guys marketing call.

    WebForms is neither one thing nor the other; it’s not fully event-driven, because it can’t be (you can’t respond to a checked_changed event in the same way you could in Winforms/Win32 because you need a postback and then you get them all at once), and it tries to hide too much of what the web is about behind a desktop programming metaphor which is wholly unsuited to the task at hand. It obfuscates your markup and munges your IDs, which in an age of WCAG/Section 508 markup validation/accessibility and Web 2.0 JS front end niceties is just another piece of grit in the lubrication. It doesn’t try to prevent you from doing architecturally inappropriate things.

    Don’t get me wrong, I loved the novelty of WebForms at first. Over time I came to realise that it stands between you and your markup, and many times between you and your sanity.

    So yes, there’s a learning curve with MVC (ASP.NET MVC or otherwise). I’d be willing to bet that once you’re at the top of that curve you’ll groan inwardly when confronted with a GridView with inline styling in your next gig…

  • Dave:

    Russell, nothing is really new. But as far as ASP.NET goes, MVC is new.

    You seem to prove several points I’ve made in the past regarding ASP.NET and WebForms.

    I’ve been doing web development since “Al Gore invented the Internet” I’ve written with notepad. I’ve used struts, I’ve used ASP 1.0 through 3.0. I’ve used ASP.NET.

    They all have their place.

    My point is not that it shouldn’t be used, but that there should be a business reason for using it.

    Maybe where you work and for the people you develop for having super clean code without “munging” and “grit” is appropriate. It could be just as appropriate for another organization to stay with what is working because their business interest are skewed toward getting something up and running as quickly as possible.

    No one tool is perfect simply because people want the tool to do different things. This goes just as much for ASP.NET MVC as it did for WebForms, Classic ASP, or Struts and Java Server Faces in the Java world.

    I’ll give ASP.NET MVC this much, it’s a whole lot easier to use than Stuts ever was.

  • Ian:

    “Over time I came to realise that it stands between you and your markup, and many times between you and your sanity.”

    Hear, hear.

    I pretty much gave up on when Ajax came out – just too ridiculously complicated. was a fascinating idea and was very challenging to work with in a good way. But now its on its way out, perhaps we can go back to creating web pages.

    “They all have their place.”

    Yes, and the place of some technologies is in the bin (or a museum).