Razor/CSHTML - Any Benefit over what we have? [closed]

Question

Anyone out there using the new CSHTML pages feature and is finding that they prefer this new view engine syntax over the existing ASP.NET MVC default view engine or over web forms, and if so, why? What about CSHTML gives you an advantage over MVC or web forms, or vice versa?

Just curious to hear people's take on it.

Cassette

I think it's possible to give objective answers to this question naming actual(objective) or perceived(subjective) benefits, but you should rephrase your question to get these. In it's current form it's too subjective and argumentative. – Threefold

I updated the question slightly. But I have to say, I'm looking for pro's and con's, and I'll take whatever response I'll get, as I'm looking at an overall level but would like to hear about technical details too, so I don't see a problem with the way I stated it... – Cassette

Is there some cheatsheet / guide for using Razor for FrontEnd Developers? I'm currently work on a Razor project, skinning the application with Foundation, and i would like to know something more on Razor that could help me. – Triste

Answer 1

One of the benefits is that Razor views can be rendered inside unit tests, this is something that was not easily possible with the previous ASP.Net renderer.

From ScottGu's announcement this is listed as one of the design goals:

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).

Algeciras

Added a link for supporting evidence :) I haven't used Razor myself yet, so I don't have code to share right now. Give it a few months and maybe I'll have time to play with the beta! – Algeciras

We haven't put out any guidance on testing Razor views but I blogged about hosting the Razor engine outside of ASP.Net: blog.andrewnurse.net/2010/07/22/… – Manichaeism

You should definitely have a look at the great Razor Templating Engine hosted on CodePlex: razorengine.codeplex.com – Defective

Wow, i never new razor view's were testable. I figured testing the output of the controllers (e.g passing correct/valid model) was enough. Anything outside of that is testing HTML output - which seems a bit silly. – Handwork

This answer (and the others as well) are still up to date? I'm wondering, with all new features and stuff that are coming out are still any benefits on using cshtml? – Alto

Answer 2

Ex Microsoft Developer's Opinion

I worked on a core team for the MSDN website. Now, I use c# razor for ecommerce sites with my programming team and we focus heavy on jQuery front end with back end c# razor pages and LINQ-Entity memory database so the pages are 1-2 millisecond response times even on nested for loops with queries and no page caching. We don't use MVC, just plain ASP.NET with razor pages being mapped with URL Rewrite module for IIS 7, no ASPX pages or ViewState or server-side event programming at all. It doesn't have the extra (unnecessary) layers MVC puts in code constructs for the regex challenged. Less is more for us. Its all lean and mean but I give props to MVC for its testability but that's all.

Razor pages have no event life cycle like ASPX pages. Its just rendering as one requested page. C# is such a great language and Razor gets out of its way nicely to let it do its job. The anonymous typing with generics and linq make life so easy with c# and razor pages. Using Razor pages will help you think and code lighter.

One of the drawback of Razor and MVC is there is no ViewState-like persistence. I needed to implement a solution for that so I ended up writing a jQuery plugin for that here -> http://www.jasonsebring.com/dumbFormState which is an HTML 5 offline storage supported plugin for form state that is working in all major browsers now. It is just for form state currently but you can use window.sessionStorage or window.localStorage very simply to store any kind of state across postbacks or even page requests, I just bothered to make it autosave and namespace it based on URL and form index so you don't have to think about it.

Ferroconcrete

Most impressive performance numbers - I dislike ASP.NET for its valiant attempt to make Web programming like VB6. Make testability a bitch. For that reason I also like MVC. Do you have an example you may share of the architecture you are using. – Babushka

To "mozillanerd", in terms of architecture, if you want to test out what I described, literally do a anonymous c# object with new such as var myobj = new { /* place data structure like similar to json */ } and have that cached in memory and see how fast LINQ is against it. Imagine this is a catalog of products and try LINQ against it. Its super fast but has its place in terms of right fit of scale as its best on one box unless you have azure caching going on and you are running it on windows azure. – Swisher

Answer 3

1. Everything is encoded by default!!! This is pretty huge.

2. Declarative helpers can be compiled so you don't need to do anything special to share them. I think they will replace .ascx controls to some extent. You have to jump through some hoops to use an .ascx control in another project.

3. You can make a section required which is nice.

Troopship

Answer 4

The biggest benefit is that the code is more succinct. The VS editor will also have the IntelliSense support that some of the other view engines don't have.

Declarative HTML Helpers also look pretty cool as doing HTML helpers within C# code reminds me of custom controls in ASP.NET. I think they took a page from partials but with the inline code.

So some definite benefits over the asp.net view engine.

With contrast to a view engine like spark though:

Spark is still more succinct, you can keep the if's and loops within a html tag itself. The markup still just feels more natural to me.

You can code partials exactly how you would do a declarative helper, you'd just pass along the variables to the partial and you have the same thing. This has been around with spark for quite awhile.

Mendoza