Today, ASP.NET developers have two options when building new Web projects: the old faithful ASP.NET Web Forms, or the young gun, ASP.NET MVC framework. Increasingly, companies are choosing ASP.NET MVC for green field development and for significant revisions of existing sites. But does ASP.NET MVC really bring concrete benefits that can be justified to upper management?

ASP.NET MVC has a lot of technical goodies that developers have fallen in love with. But, it turns out that in exchange for those benefits, ASP.NET MVC has greater startup costs. And in some applications, ASP.NET MVC is a substantial turnaround from ASP.NET Web Forms.

ASP.NET and TV Screens

It is said that Microsoft initially created ASP.NET MVC (in roughly 2007-08) as a proof of concept to demonstrate that it was possible to apply patterns such as Model-View-Controller (MVC) to ASP.NET. (The MVC pattern, which is frequently used in the design of web sites, aims to separate data, business logic, and the presentation to the user. The challenge in many cases is keeping business logic out of the presentation layer; and careful design based on MVC greatly reduces the prospect of this intermingling.) However, no IT manager will spend money on new software solely because it applies patterns. So why, then, is ASP.NET MVC gaining momentum?

ASP.NET MVC is technically superior to ASP.NET Web Forms because, having been released five years later, it addresses the business and technology changes that have occurred during the intervening period  testability, separation of concerns, ease of modification, and so on. When it comes to the core function, however, there is nearly no difference.

If you investigate the reasons for switching espoused by early adopters of ASP.NET MVC, you find a common point of origin  widespread discontent with ASP.NET Web Forms. If you think that ASP.NET Web Forms works well, then there is probably no reason for you to consider alternatives. In this case, jumping on the ASP.NET MVC bandwagon would be an instance of the notorious "Architecture as Requirements" anti-pattern, where organizations use a given technology or product simply because it's nifty and new, but for no truly compelling reason.

It's Progress, Baby

For other organizations, however, the ASP.NET MVC delivers value. The framework has grown to be fully fledged and capable of all Web development on the Microsoft platform. It has a lot of new features to offer to developers. In particular, ASP.NET MVC provides total control over HTML and it offers cleaner interaction with inline JavaScript. If this statement doesn't sound exciting enough at first, then consider that it is exactly this freedom that enables the development of pure Ajax solutions without tying a site to a specific commercial framework.

To this end, ASP.NET MVC undoes to one of the best-selling points of ASP.NET Web Forms when it was introduced a decade ago: It shielded developers from the nitty-gritty details of HTML. In contrast, ASP.NET MVC stays closer to the metal of HTML and HTTP, and it gets rid of the thick abstraction layer built on top of Web Forms (viewstate, server controls, page controllers, event-based page lifecycle).

Benefits of MVC's Closeness to the Code

Control over HTML enables developers to build Ajax applications more comfortably, and it facilitates adding more interactivity and responsiveness to existing apps. Direct control over HTML also means better accessibility for implementing compliance with evolving Web standards. The world of Web continually progresses, and ASP.NET MVC is closer than Web Forms to all emerging technology trends.

In addition, ASP.NET MVC uses interface-based contracts, which allow components to be more easily tested in isolation. As a result, cleaner and more testable code is often promoted as a good reason to embrace ASP.NET MVC. Frankly, I don't consider this a valid primary reason for its selection. Writing clean code should be a practice that transcends the technology. While it can't be denied that ASP.NET MVC is an inherently more testable framework, testability is more about isolating critical portions of code to gain visibility over internal state and control over input  two factors critical to attain the needed modularity. This practice has more to do with clean design and thoughtful code than with the surrounding framework. Put another way, your chances of writing bad code are nearly the same in Web Forms and ASP.NET MVC. But if you write bad code, MVC will make it easier to diagnose.

Towards a Strategy

The runtime environment is the same for ASP.NET Web Forms and ASP.NET MVC applications. That is, the view engine for MVC is the ASP.NET Web Forms engine. This factor enables sites to add MVC blocks incrementally to an existing ASP.NET project, and thus both test and, if desired, transition to MVC. However, MVC enables other view engines to be used as drop-in replacements for Web Forms, including Razor, an engine developed by Microsoft and now bundled with MVC.

The complexity of modern applications requires considerable attention to design: isolation of concerns, testability, scalability, and so on. With proper discipline, you can still write good quality code on top of existing ASP.NET Web Forms. The emerging wisdom, however, is that Web Forms cannot structurally serve you in the same stellar manner you may have experienced in years past. ASP.NET MVC becomes the better choice as soon as you feel Web Forms is no longer serving you at the level to which you've become accustomed. This moment is likely to arise at the point when you want to upgrade or expand customer interactivity on your site.