ASP.NET MVC Razor view engine

问题:

After reading Scott Guthrie's blog entry about the new Razor view engine for ASP.NET MVC and reading this question comparing the available view engines.

Razor seems to address most of the problems with the default view engine. What feature differences would make it a compelling choice for you as a developer? What features are lacking that would keep you from using it?

回答1:

There's much more to view engine except markup language. Few Spark features that I will miss:

• write html extensions using same markup language, not C# (macros) - I see that Razor also supports this, I hope it supports method/parameters override;
• custom tags (write _Tag.spark to use <Tag />);
• autogenerated variables like varIsFirst, varIndex, etc;
• special expression forms (?{} for conditional attributes, $!{} to skip errors, etc);
• nice master/partial layouts support, including ability to specify in partial that part of markup should be render only once in master (e.g. script includes);
• you can still have WebForms markup - great for compatibility and incremental upgrade;
• support to use both "" and '' quotes inside each other (extremely useful).

I like Spark syntax for loops/ifs more - mixing HTML <> and C# {} braces doesn't look too nice - but that's purely personal opinion.

There're very promising features in Razor, too, e.g. inline templates. Given that Spark creator was hired by Microsoft, I think there's a hope for Razor to be well written, very useful, and well supported view engine. Of course I won't re-write hundreds of my Spark views with Razor (though I did rewrite dozens of my WebForms views with Spark). But I will surely take a serious look at Razor - I only found this out from your questions, thanks - and what I see now looks promising. It doesn't compete with WebForms, of course (any view engine is better than WebForms), but it looks like a good choice for a new ASP.NET MVC project, if you haven't yet invested into another view engine too much.

回答2:

Unit Testable: The new view engine implementation will support the ability to unit test views (without requiring a controller or web-server, and can be hosted in any unit test project – no special app-domain required).

At last!!! Can't believe it took almost 8 years for Microsoft to finally bring a view engine that supports this.

回答3:

For me there are three compelling reasons:

1. Compilation - Razor views can be compiled into a DLL. At last we get proper re-usability in .NET web projects. I can have a business object that knows how to display itself without having that code floating around as .ascx files in some part of the web project.

2. Testability - as it's compiled to a class I can write a unit test and throw mocked instances of objects at it to see if the HTML is right.

3. IntelliSense and the Terse Syntax are nice but not the most important parts.

回答4:

Obviously I haven't evaluated it in practice yet, but the fact that it is terser than the ASPX engine is the most compelling feature to induce a switch. I only hope that it also auto-formats more nicely. The fact that it will be supported with intellisense and delivered with MVC makes it a natural choice for starting new projects. I'm going to give it a fair shot on a small project before I make the switch. Just from reading the article I didn't see anything that I wouldn't be able to do with it that I'm currently doing with the ASPX engine.

Update: I've been using Razor for well over a year now and would never go back to the ASPX engine. The syntax seems very natural and expressive.

回答5:

Besides the cleaner look, the flexibility of the layout sections looks very good, and the declarative HTML helpers look very useful. So far don't see any downside in using it but of course will have to give it a try in practice.

回答6:

Razor use Brackets, that is, for foreach stuff. Spark uses here XML tags.

So, Spark completely supports parsing and analysing of a view file per XML processor.

Mabye that's not a big thing, but shows consistency and extensibility.