- 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 areas. CodeCampServer 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.