Thoughts on ASP.NET MVC

I've been digging in to ASP.NET MVC recently, and have come away quite impressed.  So I thought it would be worthwhile to capture some impressions, and answer the question: "Why should I be looking at this?"

Postbacks get their own code.

The hardest thing for me to wrap my head around, and what ended up impressing me the most, was the fact that IsPostback has been banished.   Hitting the same block of Page_Load code on both GET and POST is asking for trouble ("Why isn't this value getting captured?  ASP.NET is broken!! Oh, never mind, I'm overwriting it in Page_Load. Whoops.")   MVC just doesn't go there.  Instead, you set up two methods (OK, "Controller Actions"), decorate one with a [HttpGet] attribute, and one with a [HttpPost] attribute, each with one job.  Separation of concerns, for a rosy-fresh code smell.

These attributes are called Action Filters, and they can do some pretty neat things, such as force login or set up output caching.  Action Filters can be applied to the individual Action method, the Controller class (allowing you to limit a controller to signed-in users, or members of certain role), or applied globally.  And you can roll your own by subclassing System.Web.Mvc.FilterAttribute.

Controllers handle the plumbing.

A lot of lines of code can get written getting form parameters, query strings, and URL path elements into your logic, and with MVC, this code isn't written by you.  If your action has a parameter called "name," MVC will check in all the logical places to populate it, be that a query string, a form value, or possibly the URL path itself.  Writing fewer lines of plumbing code means generating fewer bugs.

When you write in Razor, you write HTML

If you are a Web Forms developer, you may need to work with front-end developers, and may even number them among your friends. If you do, and you join one for a beer after work, you will learn that front-end devs really don't like working with the markup generated by Web Forms. And with markup that looks like this can you really blame them?

<input name="ctl00$ctl00$MainContent$Content$SearchControls$CardSearchBoxParent$CardSearchBox" type="text" id="ctl00_ctl00_MainContent_Content_SearchControls_CardSearchBoxParent_CardSearchBox" class="textboxinput" onblur="SetCurrentControlBlur(event)" onfocus="SetCurrentControlFocus(event, this);" autocomplete="off" maxlength="50" />

The drag-and-drop, "it's just like creating a Windows App," model of web development was not designed for producing clean markup.  Razor, on the other hand, was conceived to read as clean HTML, both in code and in generated output.  Basically, you write HTML, and you switch to C# when you need to by throwing in an "@":

<table>
@foreach(var employee in Employees)
{
<tr>
  <td>@employee.Name<td>
</tr>
}
</table>

It really shouldn't be this easy.

HTML Helpers

Following the theme that you shouldn't have to write the same lines of plumbing code over and over again, ASP.NET MVC allows you to generate boilerplate HTML using the HtmlHelper class.  These allow generating standard HTML features like drop-down lists, text boxes and labels, and these are generated as pure HTML, not as .Net controls.  Best of all, you can write your own.  Put some markup in a CSHTML file, name it after a domain object, place it in /Views/Shared/EditorTemplates, and when you use @Html.EditorFor(yourObject), your editing markup is called.  So you get the reusability of a custom control, while staying within standards-based HTML.

AJAX Helpers

Where MVC gets truly slick is in making AJAX feel like server-side development.  If instead of typing @Html you type @Ajax, intellisense will give you access to Javascript functionality that looks and feels like server side code. Best of all, the Javascript is "unobtrusive," meaning that it is contained in include files, and triggered by static "data-" attributes.  So no code is included in the rendered markup. In fact, keeping the Javascript respectable and high performing is a theme running through MVC.

Testability

A nice thing about controllers is that you can instantiate them, which means you can test them. In fact, all outside dependencies, such as the HttpContext object, have been refactored to be based upon abstract, and thus mockable, classes.  So build your tests, the framework is not stopping you!

What Else?

I'm still wrapping my head around this framework, and may have missed some significant points.  So here's a call to action to use the comments to call out your favorite features of coding in ASP.NET MVC.  If you want to learn more about MVC4, I highly recommend Scott Allen's courses on Pluralsight, as well as many blog posts by Phil Haack, Scott Hanselman, and Scott Guthrie.  And there's an excellent walkthrough on MSDN.  Finally, the Wrox book Professional ASP.NET MVC4 looks quite good.