Take the 2-minute tour ×


Just curious to hear people's take on it.

share|improve this question
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. –  dtb Aug 6 '10 at 12:33
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... –  Brian Mains Aug 6 '10 at 15:48
add comment

closed as not constructive by casperOne May 2 '13 at 3:40


4 Answers

up vote 36 down vote accepted




share|improve this answer
example? or link? –  rball Aug 6 '10 at 15:54
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! –  Simon Steele Aug 6 '10 at 16:46
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/… –  Andrew Nurse Aug 14 '10 at 15:43
You should definitely have a look at the great Razor Templating Engine hosted on CodePlex: razorengine.codeplex.com –  Marius Schulz Nov 16 '10 at 9:32
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. –  RPM1984 Dec 19 '10 at 23:55
show 1 more comment

To give background of opinion: I'm an ex Microsoft developer that 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.

** EDIT **

I actually am moving away from Microsoft tech altogether now and moved into Linux and node.js. I know I could have tried to continue Windows + node.js but there were too many gotchas. I still have many clients on .NET but am focusing on node.js heavily for all new endeavors. The performance, ease of code and cost is really the driving factor. Basically, its just better.

share|improve this answer
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. –  mozillanerd Aug 16 '11 at 17:21
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. –  Jason Sebring Dec 4 '11 at 4:32
add comment
  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.

share|improve this answer
add comment

The biggest benefit is that the code is more succinct. The VS editor will also have the itellesense 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.

share|improve this answer
add comment
