Probably the single biggest change in ASP.NET MVC 3 is the new Razor view engine, an alternative to the ASP.NET Web Forms view engine. The view engine takes model data from the controller and renders a web page. It uses a template that describes how it should generate the HTML based on the model data (and other data the controller sends it).
By using the Web Forms engine in MVC 1 and 2, Microsoft probably made it easier for Web Forms developers to make the jump to MVC, letting us use a syntax we were already familiar with. Various third parties released custom view engines, but nothing really ever caught on very widely since they weren't "in the box" with Visual Studio. Besides, using a third-party view engine meant learning a new syntax, adding yet another thing to learn in order to use MVC.
But MVC 3 now includes the Razor view engine. Microsoft had a number of design goals for Razor, including that it be compact and expressive, easy to learn, not new (more about this in a moment), editable in any text editor, and unit testable. By "not new," they wanted to create something that didn't involve a new imperative language. Razor uses a mix of HTML and your choice of C# or VB, with a few syntactical details. These simple details are really all you need to learn that's new with Razor.
You can use either view engine for any view in an MVC 3 application, making it easy to migrate older MVC applications forward. Keep the old views in the Web Forms engine while adding new views that use Razor. You can even create a partial view in one engine and embed it within another view that uses the other engine.
Back when I first heard about Razor, I figured that I didn't need to learn it, since the Web Forms engine was working just fine for my applications (as ugly and bloated as the syntax often is!). But since I've worked with it a lot and have a few applications under my belt with Razor, I plan to never go back to Web Forms, if I can avoid it. You have the choice of engines though, and Microsoft has promised to keep moving them forward together.
Differences Between Razor and Web Forms Views
I won't get into too much detail here about the Razor syntax, but I want to give you a taste of how it differs from Web Forms and whet your appetite a bit. The fundamental difference is the syntax used to embed code nuggets in a view. Here is a code nugget from a Web Forms view:
<%: Html.ActionLink("Register", "Register") %>
And below is the equivalent nugget in Razor. Razor uses an @ symbol to begin a code nugget. It doesn't require anything to close the code nugget because it has semantic knowledge of the HTML in the view and the C# or VB in the code nugget. In other words, it knows enough about HTML and C#/VB to know, in by far most cases, where one ends and the other begins.
@Html.ActionLink("Register", "Register")
Just in this single statement, you've saved six keystrokes with Razor, and many statements will save way more. That is a lot of keystrokes in a typical view! You can already see how Razor can be more productive, but it gets better. Compare the two images, each of which is taken of the standard Logon view of the Account controller of a brand new MVC 3 application. (I'll use C# examples here, but everything I talk about applies to VB as well.) This first image uses the Web Forms engine:
ASP.NET MVC 3 Web Forms example
And the next image is the same view using the Razor view engine:
ASP.NET MVC 3 Razor view engine example
Just by scanning the two images lightly you can see how much cleaner and simpler the Razor syntax is. Notice, too, that you don't even have to specify the language of the view; Razor is smart enough (if I may anthropomorphize here) to determine whether you are using VB or C#.
This gives you just a taste of why I think that the Razor view engine is far superior to Web Forms. The Razor syntax can seem a bit awkward at first, particularly as you get into some edge cases where there isn't a direct syntactical equivalent for something in the Web Forms engine. But Razor is easy to learn.
Next time I'll explore some of the interesting differences between the Razor and Web Forms engines. And with any luck, Microsoft will have released the final version of MVC 3, so that we can all be playing with the final bits.
This article is derived from MVC courseware that I'm developing for AppDev.