Working with the ASP.NET MVC 3 Razor View Engine

Get under the hood of the ASP.NET MVC 3 framework and you’ll find a recently released view engine named Razor. Razor uses a new construct by leveraging C# and VB.NET code within a new type of view that, at first, will seem foreign to ASP.NET developers. At an elementary level, Razor replaces a bunch of <% %> statements with "@" and "@ { }" statements. But here under the hood, there’s a lot more going on.

Razor takes its cue from some of the other popular view engines, such as Spark and NHaml. Razor seeks to add simplicity to the process by combining C# or VB code with a new inline syntax that's flexible yet compact. Scott Guthrie, corporate vice president for the Microsoft .NET developer platform, laid out the following design team goals for the Razor framework:

• compact, expressive, and fluid
• easy to learn
• C# and VB.NET-oriented
• IntelliSense supportable
• unit testable

We're going to examine the product to determine how it meets these design goals. But before we discuss Razor, I want to reiterate that the concept of MVC has not changed in this latest release. Also unchanged are the constructs and their controllers, the inline project areas, and the models However, these components have been enhanced by some new features, such as dependency injection and new attributes. As an ASP.NET MVC developer, you’ll be comfortable with the back-end features, and you should be able to adapt to the new view constructs fairly quickly.

Setting Up a Project

You can create an ASP.NET MVC 3 Razor website in Visual Studio by using a template similar to the ASP.NET MVC view engine format. Figure 1 shows an example of a new Razor website. (I've modified the default setup somewhat).

The MVC web application template has been upgraded to include jQuery UI scripts and styles, validation and MVC integration points (for a richer client-side experience), and a slew of cshtml or vbhtml files, which are the new file formats for Razor views (using the respective languages).

You may notice some differences between this project and one that uses the ASP.NET MVC view engine. For one thing, this project includes a _viewstart.cshtml file that seems to have some special meaning. Additionally, certain files begin with an underscore character. The underscore is a special designation that marks a page as private and not servable to the public. This means that this page cannot be requested directly by the browser. Instead, the page is used for partial views, layout files, and other nonpublic needs.

Project Item Templates

In ASP.NET MVC 3, new Visual Studio project item templates now appear under the MVC 3 category in the Add New Item window. Figure 2 shows the following options for ASP.NET MVC 3:

• MVC 3 Layout Page: the layout for MVC 3 pages, similar to a master page
• MVC 3 Partial Page: a partial page or view for MVC 3
• MVC 3 View Page: a view for MVC 3 that doesn't use a Layout page
• MVC 3 View Page With Layout: a view for MVC 3, which uses a layout page

In Figure 2, note the indication (in parentheses) of the ASPX or Razor templates.

Syntax

The Razor view engine, similar to the ASP.NET MVC view engine, mixes server-side logic with client-side HTML/JavaScript and now uses the at sign (@) to identify its code segments. The Razor view engine inspects the body of a view for statements that typically begin with @. The engine parses the content to determine whether it's pure content or happens to be server-side code. For instance, if the engine finds the statement "@Model.Name," it interprets this as server-side code. However, "[email protected]" renders as client-side content because of the syntax.

The Razor engine parser is pretty intelligent. It knows what you are typing, and it knows whether the @ sign is identifying server-side or client-side content. Any identified server-side code uses a special yellow highlighting to highlight the @ and gives the code a gray background. However, when you type an email address, this is interpreted correctly as client-side HTML. As soon as the parser interprets characters such as a space, closing HTML tags, or quotation marks to end an HTML attribute, the parser stops highlighting the text and begins interpreting the content as client-side code.

Interestingly enough, this approach works well. We rarely run into situations in which spaces are injected into code (except in a string, which is specifically identified by quotation marks). Also, only a few special characters are allowed by the C# or VB.NET compiler.

It's easy to play around with the view engine to figure out which combinations of content are supported. The following list of scenarios indicates how the view engine interprets the content in each case:

• @Model.State: interpreted as server-side code
• [email protected]: interpreted as client-side code
• t @Model.State: interpreted as a mix of client and server content
• @Model.State State: interpreted as a mix of client and server content
• Test: correctly renders server-side content into the href attribute of the hyperlink
• Test: correctly mixes the state server-side value into the client-side href attribute of the hyperlink

In some cases, you may have to force the parser to recognize pure server-side content. Razor may incorrectly parse certain constructs as client-side content. For instance, what if we wanted to use generics? The parsing engine recognizes generics as HTML content. This interpretation wreaks havoc, so this is where some new constructs come into play. If the code can fit into a single statement, use @ together with parenthesis, as in the following:

@(  )

The code within the parenthesis is recognized as pure server-side content.

Sometimes, we must have a larger code block made available to us. Curly brackets denote a code block or segment within Razor. But code blocks are not purely server-side content; they can be mixed. Note the differences between the two syntactic examples in Figure 3.

	State: @((Model.State == "FL") ? "33426" : "11111")


	@{
		if (Model.State == "FL") {
			
				33426
			
		}
		else {
			
				11111
			
		}
	}

Code blocks can mix client-side content, but this requires the use of either an HTML element or the new element. The element doesn't actually render anything; instead, it's a clear and concise way to identify client-side text. This element is required because Razor can't accurately determine the transition from a server-side if statement to client-side content. Any HTML tag or the tag is a clear demarcation of this transition.

Code Structures

The Razor view engine supports most, if not all, code structures in your favorite .NET language. It uses the inline or code block approach. The example in Figure 4 illustrates some of the various code structures in C#.

	@foreach (var item in Model.Items)
	{
		
	}
	

	

		

			
Name
			
Value
			
Is Active
		
	
	

			
@item.Name
			
@((item.Value != null) ? item.Value : null)
			

				@switch (item.IsActive)
				{
					case true:
		Active
		break;
					case false:
		Inactive
					default:
		Unknown
		break;
				}
			
		

Razor also supports if/else statements, While loops, Do...While loops, and all other code structures available to developers in C# or in VB.

View Headers

Headers in a Razor implementation also differ from the standard @Page header used in ASPX pages. In ASP.NET Web Forms or MVC views, the header contains all the common settings defined for the page. The settings can also be set in code.

The Razor view engine doesn't use quite the same approach. Instead, it uses a code block to define these common page settings, typically at the top of the page. Figure 4 compares the differences between the two implementations.

Notice that we don't have to specify the base class or the development language. This is especially true of the latter because the page extension itself has C# in the name! In Razor, there is no explicit title property. However, the title element that's defined in the master page references the same ViewBag.Title expression that's defined in Figure 5. The ViewBag dynamic object is a dynamic version of the ViewData dictionary—an easy way to pass properties from a controller or from a view to the view or to the layout page.

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>

@{
    ViewBag.Title = "Index";
    Layout = "~/Views/Shared/_Layout.cshtml";
}

For custom base classes, the earliest versions of ASP.NET MVC 3 used an @inherits statement. In later releases, the @model keyword was supported as a more concise way of defining a model. This keyword also let developers avoid having to explicitly define the base page over and over again. Instead of this definition, we can make use of a new configuration section to set up the base page class for all our view pages. This section is shown in Figure 6.

Helpers

The Razor view engine has a lot of utilities in its arsenal. Among its potent weapons are helpers, which provide another way to create reusability within an application. A helper is defined within the view and provides a reusable snippet within the application. This feature resembles ASP.NET Web Forms that have user controls. However, the syntax is more concise and compact, and the logic fits together into one package. You can see these differences in the example in Figure 7.

@helper SomeHelper(string text)
{
	if (text != null)
	{
		
			@text
		
	}
	else
	{
		
			Unknown
			
	}
}
.
.

Helper with Text:

@SomeHelper("This is not null text.")