I prefer using MVC over Web Forms for ASP.NET development, but the reasons are getting narrower as Web Forms is improving.  Here's my "Why should I use MVC" list from a recent presentation:

  • To get separation of concerns right from the start
  • To avoid ViewState page bloat
  • To avoid messy HTML
  • To avoid messy URLs

But a lot of this is changing in Web Forms with ASP.NET 4.

ViewState Improvements

In previous Web Forms versions, you could disable ViewState for the page with EnableViewState="False", but the controls on your page still had their own ViewState.  You had to explicitly turn it off for every control in the page to make it really go away.

Now there is a ViewStateMode property that the controls in the form pay attention to.  You can disable ViewState for the page with:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Default"  ViewStateMode="Disabled" %>

And just set ViewStateMode="Enabled" for controls where you need it.  This is the way it probably should have worked all along.  You'll still have view state, but you turn it on where it makes sense instead of having it on all over the place clogging up your response.

Rendered HTML Improvements

Now that we're all doing more client-side development with JavaScript once again, we need to grab control IDs.  We've all seen view source screens with nightmare IDs like:

<span id="ctl00_MainContent_uxdPHAllContent_TripSelector_lblFromDate">
From Date:
</span>
<input type="text" name="ctl00$MainContent$uxdPHAllContent$TripSelector$txtFromDate" id="ctl00_MainContent_uxdPHAllContent_TripSelector_txtFromDate" />

This happens when server controls are nested inside other server controls.  If you use Master Pages and ContentPlaceHolders, everything looks like this.

Now there is a ClientIDMode property of controls.  You can set ClientIDMode="Static" in the container control to get your exact ID or set ClientIDMode="Predictable" to get an ID you can expect in the rendered HTML.

Another rendering improvement coming in Web Forms is in the ControlRenderingCompatibilityVersion property.  It's a mouthful, but set that guy to 4.0 (side note: why "4.0" instead of just "4"?) in your web.config:

<pages controlRenderingCompatibilityVersion="4.0"/>

You get XHTML 1.0 Strict markup, menu HTML that look like a list (UL and LI tags), and fewer inline style setting like on validation controls.

URL Improvements

You're Marketing department has probably asked you for tighter, prettier URLs at some point.  Vanity URLs are a marketer's dream.  With MVC, creating clean, simple URLs is easy.  Now Web Forms has that same goodness.

The MVC URL routing engine is in System.Web.Routing, so it's not just for MVC anymore.  You can get those URLs marketers always want like http://mysite.com/CoolNewProduct without the coding hassles of old.

Conclusion

Web Forms will still have the post-back model, and MVC will still have Controllers with Actions.  And I would still rather work on an MVC project versus a Web Forms project.  But that can now mostly be for architectural reasons rather than framework artifact reasons.

I like the separation of concerns in MVC better, and I think once you get used to routing and Controllers and Actions in MVC, the Web Forms model seems very un-web like.  I also think MVC projects are much more testable. 

But I am glad to see Microsoft making these improvements in Web Forms.  It was due for some tidying up!