You should NOT use ASP.NET MVC if. . .

  • You are not very comfortable with polymorphism
  • You aren’t willing to build on top of the framework
  • You rely on 3rd party vendor controls for lots of the UI
  • You are averse to using open-source libraries

The above are four quick reasons why WebForms may be a better for for some time to come if you are an ASP.NET developer wondering whether you should upgrade to ASP.NET MVC.  Please understand that I have switched all of my employees to this latest version of ASP.NET for all client projects.  I’m also writing a book, ASP.NET MVC in Action for Manning with two great co-authors, Ben Scheirman and Jimmy Bogard, both of which write about the framework on their respective blogs.

You should NOT use ASP.NET MVC if. . . You are not very comfortable with polymorphism

ASP.NET MVC makes use of interfaces, abstract classes, virtual methods and some psuedo-AOP.  If you are not well-versed with these object-oriented concepts, then the framework might not be very friendly for you.  While WebForms uses the template method to give the developer some well-defined places to put code, the MVC framework specifies an array of extension points that leverage the power of object-oriented programming to add on and extend the framework. 

You should NOT use ASP.NET MVC if. . .You aren’t willing to build on top of the framework

Version 1 of ASP.NET MVC is just a framework.  WebForms was a framework as well as lots of plugins and features.  ASP.NET MVC has very few features.  It has some basic url helpers, html helpers, and ajax helpers.  Even these are light on maintainability and are very basic.  They leverage string literals to do their job.  Without custom abstractions built on top of these, it will be difficult to develop a maintainable application that is more than a handful of pages.  This is not a failing of the ASP.NET MVC Framework.  This is just how it is, and I think it is the strength of a flexible framework.  Jimmy Bogard describes here some of the custom abstracts we have built in order to ensure our applications are maintainable.

You should NOT use ASP.NET MVC if. . . You rely on 3rd party vendor controls for lots of the UI

There are lots of 3rd party controls and extensions for WebForms in the marketplace.  There is so much out there that you can do quite a bit without a whole lot of code.  ASP.NET MVC doesn’t have lots of extensions in the marketplace.  In fact, many of the extension are in completely unsupported places.  Steve Sanderson talks about a mechanism for areasCodeCampServer has some smart input builders.  MvcContrib has lots of goodies.  These are not supported by a vender, and the major ASP.NET component vendors don’t have offerings for ASP.NET MVC, and it is unclear how venders will package and deliver commercial extensions.  I think it’s only a matter of time, but it isn’t there yet.

You should NOT use ASP.NET MVC if. . . You are averse to using open-source libraries

Many of the competing MVC-based frameworks are open-source.  Java has several MVC implementations, and the whole of Java is open-source.  MonoRail is open-source, Rails is open-source.  ASP.NET MVC is source out in the open.  The currently offered extensions for ASP.NET MVC are all open-source or public domain (posted on blogs).  If you are unable to use code or extensions from open-source libraries, then you will have to build everything yourself, and that goes back to item number two.  MvcContrib has lots of extensions for the ASP.NET MVC Framework, and CodeCampServer uses some custom extensions that haven’t made it to MvcContrib yet (but are free for the taking).  In short, extensions are out there, but there is not one, or many, commercial vendors selling them.  They are in open-source projects out there in the community.  If you are adverse to open-source and want all the good stuff to come from Microsoft or a Microsoft Gold Partner, WebForms may be a friendlier environment.

Jimmy Bogard has recently posted on some of the techniques that we, Headspring Systems, use when building web applications on top of the ASP.NET MVC Framework.  In early 2008, I led a team that put a MonoRail application into production.  Jimmy was on that team.  From that experience, we have decided that Castle Validators are a natural fit for validating data integrity of the EditModel (the type being bound by the model binder when a form is submitted to a controller action).  This is not business rule validation.  This is merely things like: “can the characters that were submitted be parsed into a date, an int, a guid”, etc.  Once we get passed data type validation, then the domain model can work on the more interesting business rules.

This is just one of the many ways that existing frameworks can be integrated with ASP.NET MVC.  ASP.NET MVC is a wide-open framework.  You can do what you want with it.  That includes getting rid of it or replacing half of it.  Or even reimplementing a portion of it, like Jeremy Miller writes about.  If you want to intercept at the IRouteHandler level and dispense with controllers and actions, you are free to do so.  There is nothing standing in your way, and there are no brick walls.  It is near frictionless web development for us.

Html generations, which includes ID generation, is one of the areas where we have put in a lot of work.  Even in WebForms, you had to specify the last bit of an ID, and the framework would munge it to make sure it was unique.  This made it difficult for javascript and css based on IDs.  Because the ASP.NET MVC Framework gives us complete control, we decided to take control of how the IDs were generated.  We created a little bit of code that generated IDs based on the properties of the ViewModel or EditModel.  Because we have code that generates these IDs based on a type (class), we can generate these IDs elsewhere, like in our JQuery script blocks and even our WatiN tests.  What does this mean?  This means that we have ZERO risk that an ID change will break some JQuery or an automated UI test.  We segregate IDs used for CSS by convention to avoid the risk of CSS bugs too. 

By default, it is easy to have duplicated strings all over the place, but the application of solid programming principle, such as “Don’t Repeat Yourself” (DRY), lead us to simple abstractions that produce more maintainable code.

The ASP.NET MVC Framework is an enabling framework.  It is not a “hold your hand” framework.  It is not a “ASP.NET 101” framework.  You have complete control over everything.  UI patterns in the web space are not so standardized that we can turn over control to frameworks that work in the “standard” way.  Data access has reached this point where we know we need Create, Read, Update, Delete, cascading persistence, lazy loading, etc.  There are many Object-Relational Mappers that support the common operations, and many developers are content giving up complete control over data access because of the similar way leading ORMs work (Hibernate/NHibernate).

ASP.NET MVC in Action goes into some of these principles.  The books spends only a few pages covering the “default” way to write an application with ASP.NET MVC.  It then moves into ways that help you write better (more maintainable) apps.  The framework is not opinionated, but it allows you to be.


Reflective Perspective - Chris Alcock » The Morning Brew #335 Posted on 4.27.2009 at 2:41 AM

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #335

You should NOT use ASP.NET MVC if. . . Posted on 4.27.2009 at 8:12 AM

You've been kicked (a good thing) - Trackback from

Summary 24.04.2009 – 26.04.2009 « Bogdan Brinzarea’s blog Posted on 4.27.2009 at 10:06 AM

Pingback from Summary 24.04.2009 – 26.04.2009 « Bogdan Brinzarea’s blog

ASP.NET MVC Archived Buzz, Page 1 Posted on 5.04.2009 at 3:10 AM

Pingback from ASP.NET MVC Archived Buzz, Page 1

Os desenvolvedores ASP.NET devem aprender ASP.NET MVC? Posted on 6.12.2009 at 6:55 PM

Os desenvolvedores ASP.NET devem aprender ASP.NET MVC?

Os desenvolvedores ASP.NET devem aprender ASP.NET MVC? Posted on 9.15.2009 at 7:23 AM

Os desenvolvedores ASP.NET devem aprender ASP.NET MVC?


Kevin Dente said on 4.26.2009 at 11:16 PM

Any plans to open source any of that infrastructure you guys have built on MVC? Sounds like some very useful stuff.

Abdel said on 4.27.2009 at 2:27 AM

Really good tips.. thanks for the article!

Hadi Hariri said on 4.27.2009 at 4:03 AM

As I always say, ASP.NET MVC puts the web back into web programming. Don't like web technology, you'll have a hard time with it.

btw, ASP.NET MVC is now open source,

Casey said on 4.27.2009 at 7:39 AM

Reason 3 is valid, reason 4 is possibly valid ...

1 and 2 though just don't apply ... MVC is infinitely easier than Webforms, even if you have no idea how inheritance or interfaces work - out of the box it is far more powerful - and more importantly you won't find yourself chasing your own tail like you do in Webforms.

I can teach a mildly trained monkey to write an MVC app, just trying to explain Postback to that monkey will cause his little simian brain to explode in a pile of goo!

Chris Canal said on 4.27.2009 at 7:52 AM


I think points 1 & 2 are valid for existing WebForm developers, and I hope I'm being overly perssiemtic, and will probably apply to most ASP.NET developers. But I completely agree, I have demoed WebForms to a number of PHP/Ruby developers and they just glaze over and start mumbling to themselves.

As an old ASP/PHP developer, being closed to the metal is awesome. WebForms really is trying to solve a problem that didn't really exist.

Jeffrey Palermo said on 4.27.2009 at 8:20 AM


ASP.NET MVC is not open-source. There is no path to accept patches, and we are forbidden from redistributing the source whether we modify it our not. The source is merely out in the open on

Jeffrey Palermo said on 4.27.2009 at 8:22 AM


WebForms solved a problem that _did_ exist. Let's review:

- non-standard browsers that needed different markup to even function

- A world of VB6 programmers that needed an easy migration to the web

I would say that the first problem worked itself out, and that Microsoft succeeded on the second.

Neal Lindsay said on 4.27.2009 at 8:49 AM

Small grammar point - feel free to delete:

I think you meant "averse" instead of "adverse" on #4.

Mark Brackett said on 4.27.2009 at 9:06 AM

@Jeffrey -

MVC *is* open source[1] under the MS-PL, as defined by the OSI[2]. While I don't think they accept patches, you can redistribute it and modifications.

"Each contributor grants you reproduce its contribution, prepare derivative works of its contribution, and distribute its contribution or any derivative works that you create."



Jeffrey Palermo said on 4.27.2009 at 9:30 AM


Wow. I stand corrected. Thank you.

Kevin L. Kitchens said on 4.27.2009 at 9:37 AM

Some errors... First off, ASP.NET MVC is not an "upgrade". it's not a "downgrade" either -- it's ONLY an alternative. Probably a good and valuable alternative to WebForms, but just an alternative.

It's also not the "latest version of ASP.NET" (if that's what you meant and not 3.5).

Each of MVC and WebForms for ASP.NET are frameworks that you can utilizes as you best see fit. Apart from TDD however, no really good arguments have been made for MVC over WebForms.

Colin Jack said on 4.27.2009 at 10:41 AM

Be very interested in reading more about the exact EditModel and ViewModel approach you guys have gone for, sounds like interesting stuff.

Colin Jack said on 4.27.2009 at 11:01 AM

"Because we have code that generates these IDs based on a type (class), we can generate these IDs elsewhere, like in our JQuery script blocks and even our WatiN tests. What does this mean? This means that we have ZERO risk that an ID change will break some JQuery or an automated UI test. We segregate IDs used for CSS by convention to avoid the risk of CSS bugs too."

Double comment but I'd be interested in reading more about this...what approach do you use for generating them in the JQuery?

Hadi Hariri said on 4.27.2009 at 11:05 AM

They actually changed the license a few weeks back. That's one reason you can now use it under Mono.

Chris Canal said on 4.27.2009 at 11:10 AM


1) And as Microsoft developers we needed them to hold our hand while the rest of the web development community just got on with it? And we all know the markup spat out by controls where fantastic ;)

How many ASP.NET developers don't know how to write standards compliant Html and Css? WebForms introduced crutch where one shouldn't have been and the result is a generation of rather clueless Web Developers. How many "Where are user controls in Mvc?" questions will appear at StackOverflow?

2) That's not strictly true. A lot of VB6 developers jumped ship. I did read something about this, I will look it out and post it. Althought I might be remembering it incorrectly so I reserve the right to be wrong.


Bryan Napier said on 4.30.2009 at 2:56 PM

Apparently telerik's radcontrol suite does have support for ASP.NET MVC. From telerik's site:

"Microsoft ASP.NET MVC -ready

With RadControls you no longer have to stick with simplistic UIs in your MVC Views. Telerik UI controls support Microsoft MVC and allow you to combine the testability and separation of concerns of the emerging technology with the richness of traditional ASP.NET server controls. See demo or visit our MVC Forums"

Tony Lombardo said on 5.21.2009 at 10:41 AM

There's a reason for a lack of MVC 'controls'. The biggest reason has been a lack of any sort of control framework. Compounding the problem is the fact that the MVC community appears to be split between whether or not controls even make sense in MVC. We can throw together a hack wrapper of just about any ASP.NET control and have it spit out HTML in MVC- but does that make it an MVC control? Not in my mind. That's actually the main reason Infragistics hasn't stamped their controls 'MVC Ready'. What is the benefit of demonstrating a bad practice in using MVC?

I have to agree with Kevin above - MVC is not an Upgrade to WebForms. There are too many WebForms developers out there who think they need to migrate to MVC, just because..

And Chris, I'm sure you don't still use an abacus to do your math, and probably have long forgotten how to calculate sin and cos of numbers without a calculator right? WebForms and WebControls are the same idea. Why should you have to worry about the (relatively) small stuff, when you've got tons of business logic that you have to write. A web developer who is confused about a 'postback' has a good chance of building a less than stellar user experience. Tracking state is not an easy thing to do, and in most cases a web developer will create a simpler UI that doesn't require state tracking if it's not in the framework to begin with. And again, who wants to worry about that aspect, when you've got 2 weeks of business logic to write?

I think MVC is a nice alternative to a select set of problems. I think WebForms is a great framework that itslef fits a select set of problems. There's a lot of talk over the sub set of problems that MVC solves which WebForms didn't, or solved poorly. But no one seems to be talking about the set of problems that WebForms has already solved (and quite sucessfully last I checked). I argue that developers didn't use WebForms and web controls as a crutch, so much as a shoulder to stand on. UI's and UserExperience has improved dramatically over the years, mainly thanks to WebControls.

If any of you want to discuss this more, I encourage you to email me at tonyl @infragistics I'm certainly interested in what you would like to see in terms of MVC controls, and how you would plan to use them.

Blackjack in rete said on 9.21.2009 at 1:12 AM

I really appreciate your work to this site.