Exploring ASP.NET & Web Development
Does ASP.NET MVC Let Me Stop Fighting Web Forms?
By Don Kiely
I've been thinking a lot about Web Forms lately. In the spring I began what was a fairly straightforward administrative application for a client to control some of the back-end processes behind their commercial website. The application manages memberships, certain types of product and service orders, and other functions. It's an ASP.NET Web Forms application, making heavy use of data-bound grid controls (using both data source controls and ADO.NET code when warranted), and a little AJAX. Fairly typical stuff, although some of the client's quirky requirements made for some interesting challenges!
But even the straightforward stuff was a challenge at times. For example, in a recent column, "Synchronized DropDownLists", I wrote about the problem of synchronizing two drop-down lists bound to a database. I was amazed that having a bound drop-down list (bound both for the contents of the list and the current selection) synchronized to another drop-down list is not easy in a ListView control. The eventual solution wasn't complex, but it wasn't easy to figure out and is, at best, convoluted. And there were many other struggles.
I realized that the problem with Web Forms is that although the straightforward stuff is easy and often code free (not that code free is necessarily a good thing), if you stray just a little off the main path things get very complex very quickly. Far too often I find myself fighting the Page life cycle and struggling with events, finding the magic goo to make everything work. You can certainly accuse me of being an inept Web Forms developer, but even so this stuff shouldn't be so hard.
On top of this, I've been working with a client for some years, maintaining their large, complex, classic ASP commercial website. I just can't believe that in 2009 I'm still writing VBScript. But they are a great client, fun to work with, and we're gradually moving them to newer, better, and more secure technologies. Classic ASP uses this ugly model of coding that mixes inline, server-side script code (in our case VBScript) with HTML to produce dynamic pages. It was revolutionary in its day back in the last millennium but encourages bad practices such as data access code directly within the page. It makes for sites that are a nightmare to maintain.
ASP.NET MVC is an attractive alternative to Web Forms, at least conceptually. It uses the proven model-view-controller pattern to get away from the Page and postback model of Web Forms, giving the developer far more control over HTML and other design elements. Microsoft released the first version of MVC some months ago and recently released a preview of version 2.0 (go to http://www.asp.net/mvc/ for more information).
The big attraction of MVC is that it removes the barriers between me and what appears in the page. There is less black-box overhead that I have little or no control over; there is less fighting the flow of page processing.
I'm a whitewater kayaker and canoer, and one of my earliest lessons was that I don't want to ever fight the river. Even the smallest boatable creek is too strong for me to win that battle. Instead, I want to work with the river to get to where I want to go, whether it's a wave, hole, or across the river. Harnessed well, I can use the river to accomplish almost anything I want to do.
More and more, with Web Forms I feel like I'm fighting the river, trying to bend it to my will or at least find the magic combination of event code and property settings to do what I need. With MVC I feel like I'm using ASP.NET in more natural ways to accomplish my goals for a page and application. This is a far more pleasant way to develop, even if it means a bit more work!
Most of the discussion of MVC versus Web Forms centers around MVC's better separation of concerns (SoC) and its testability. SoC deals with separating software into distinct features that don't overlap or overlap only a bit. It isn't impossible to have clean SoC with Web Forms, but MVC almost pushes you in that direction. And, of course, you can fight the system and mess up SoC in MVC if you try really hard.
MVC's testability is less of an attraction for me because I don't practice test-driven development (TDD). But it is appealing nonetheless because I can easily write targeted tests that validate parts of my implementation that I am most concerned with. I don't do that sort of thing now with Web Forms don't even try but if it is an efficient way to help me deliver more robust applications, I'm so on it.
One of the few things that bothers me about MVC is that its style of development hearkens back to classic ASP (and, for that matter, PHP) in that a typical page has a mix of code and HTML interspersed in this messy mix of context switches. But MVC has a much better SoC approach (whereas ASP had none) that encourages clean, logical code. Time will tell if I can let go of that slimy feeling I get with ASP when I write MVC apps.
Over time, Microsoft is adding features that will help reduce the amount of code you need to write for an MVC application compared to Web Forms. (For example, templated helpers, which let you automatically associate edit and display elements with data types, looks intriguing.) But only time will tell whether that becomes too much like the gooey mess I have to deal with in Web Forms with the postbacks, the Page object and events, and other things I have to fight against far too much. I dearly hope that MVC will remain lean and mean while offering productivity enhancements for developers.
The impending release of the second version of MVC will only make it stronger and a more viable alternative for creating ASP.NET-based web applications. Of course, there are a lot of enhancements coming in ASP.NET 4.0 that will make Web Forms better and ease some of its problems. You can find a summary of what's coming in MVC 2.0 on the ASP.NET MVC Roadmap page on Codeplex.
The major component vendors are starting to release products with support for ASP.NET MVC, so all your favorite widgets are likely to be available. That will make developing MVC applications even easier.
Here are the two best analyses of Web Forms versus MVC that I've found:
Rick Stahl's blog entry, "What's Ailing ASP.NET Web Forms." This postdates back to 2007 when MVC was just announced by Microsoft, but still has some of the most insightful analysis of the differences in the two technologies. And although it strays somewhat from the topic, it led to some very interesting comment discussions.
Dino Esposito's "Comparing Web Forms and ASP.NET MVC article" in the July 2009 issue of MSDN Magazine. This article provides a concise summary of the differences between the two technologies, long after the first release of MVC. More than most discussions you'll find, it gives a balanced view that should support your decision to go with either technology.
There are plenty of other analyses and discussions on the topic around the web, which a Google or Bing search will readily find.
In the end, use the version of ASP.NET that is best for you and your application. Web Forms are decidedly not dead and are as viable as ever. Neither technology is going away anytime soon, and Microsoft has committed to aggressively improve both. But for me, right now, right here, MVC is proving to be an almost irresistibly compelling because I don't seem to have to fight with it so much to do what I need. And that is compelling indeed.
Don Kiely ([email protected]), MVP, MCSD, is a senior technology consultant, building custom applications and providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office.