Practical ASP.NET

Productivity Enhancements in ASP.NET MVC 3

Peter Vogel takes a look at Razor and the productivity gains in generating views that ASP.NET MVC 3 provides to developers.

• By Peter Vogel
• 03/17/2011

As I discussed in earlier columns on ASP.NET MVC, I think that the chief issue organizations will be concerned with in adopting the tool will be developers' productivity compared to ASP.NET. While organizations may value the additional reliability that extending test driven development throughout the whole application will give them, they may balk at giving up the powerful UI controls (both in the box and from the third party market) that come with ASP.NET.

For instance, while I've seen several articles on how to support paging in an ASP.NET table, none of them are as quick as checking off the paging option in ASP.NET DataView. While adding a grid of data to an ASP.NET form can be done with a few mouse drags and some property settings, generating the necessary HTML and code in ASP.NET MVC is a much more time consuming process. This may not be a bad thing if you're paid by the hour (as I am) but most organizations will be concerned unless they are guaranteed this extra time will be offset by reduced time spent in other activities (e.g. in quality assurance and end user testing).

Obviously, if ASP.NET MVC can achieve productivity levels in the same ballpark as ASP.NET when it comes to generating an application's UI -- the View -- these concerns disappear. So it's not surprising that many of the new features in ASP.NET MVC 3 are aimed right at this issue.

ASP.NET MVC3 is certainly more flexible than previous versions. When you create a new project you have the ability to select the engines that will generate your Views and that will manage your testing. The testing engine defaults to Visual Studio Test (the only one delivered with Visual Studio). But the View engine choice offers you two alternatives: the original ASP.NET engine and Microsoft's new Razor engine. And it's Razor that's designed to reduce the time to create a rich View in ASP.NET MVC.

There's no doubt that Razor significantly reduces the number of keystrokes required compared to previous versions of ASP.NET MVC. To begin with, there's no need to type in script blocks anymore -- a single character (@) indicates the presence of code. If you have a variable called "world", it's the difference between typing this:

Hello, <%= world %>.

And typing this:

Hello, @world.

There is going to be the odd time when, if you have content that uses the @ sign (e.g. an e-mail address) that Razor may not do the right thing. Where you're mixing code and text, depending on your language, the politic insertion of some HTML tags may also be necessary to ensure that Razor doesn't misinterpret your intent. In this C# example, the span tags are present just to keep Razor from confusing code and text:

@if (status == "Rejected") {
	<span>
		Your order has been @status
	</span>
}

In Visual Basic, I'd need to put the @ sign in front of my opening tag:

@If status = "Rejected" Then
	@<span>
		Your order has been @status
	</span>
End if

But in Visual Basic, if I had no use for the span tags, I could also use the @: combination to ensure Razor doesn't get confused:

@If status = "Rejected" Then
	@:Your order has been @status
End if

These are exactly the kind of finger movements that become second nature to developers working with a specific tool.

But what about those UI controls that ASP.NET developers take for granted? The WebGrid provides an example of what to expect in that area. This code creates a WebGrid, binds it to the data in the Model assigned to the view, specifies the sort column, and -- just like an ASP.NET GridView -- enables paging in a few keystrokes:

@Code
     Dim grid = New WebGrid(source:=Model,
                      defaultSort:="CompanyName",
                      rowsPerPage:=4)
End code 

This is a genuine control that accepts properties and does the right thing at runtime -- it's not a wizard generating unmodifiable batches of HTML. For instance, I can change the sort column by updating the relevant property:

grid.SortColumn = "CompanyId"

When I'm ready to display the grid I can call its GetHTML method.

Of course, the problem with this increased functionality is that I'm making my View "smarter" and, as a result, starting to defeat TDD. If I have logic in the view that is changing the sort order, I may have to resort to human-based testing to ensure that the page renders correctly under all circumstances.

There's a lot missing here that ASP.NET developers take for granted -- no server side events for instance. But, then, doing without those events is exactly what the MVC paradigm is all about.