Is using Razor kinda like going back to classic asp [closed]

Question

I'm looking at the Razor engine and I'm wondering how it's "different" compared to the initial classic ASP implementation where the server-side and front-end code where in the same page.

Why should I care about Razor?

Answer 1

In classic ASP, you used to have business code in your file ("Fetch stuff from the database and act on it").

In ASP.net MVC - regardless if you use the ASPX or Razor View Engine - you are dealing with View Logic. Things like "I have 20 Employees, display them in a table" or "If this number is negative, display it in red instead of black".

The business logic is in the controllers and lower. The controller then passes the business data to the view through a view model. The View then only has code that handles displaying it, which is usually trivial but can have a few logic branches of it's own ("Display Dates in the Users Locale" or "Display male and female employees in separate tables")

You can make the mistake of putting business logic here. Say, employees hired before 2008 are eligible to a Certificate of Loyalty. So your table has a column "Print Certificate" that is only displayed for these. The simple, but wrong approach is to put an if-statement:

@if(employee.HireYear <= 2008) {
    Html.ActionLink("Print Certificate","Certificate","Cheese",
        new { id = employee.Id }, null);
}

This works, but is wrong because the view now contains business logic. The correct approach is adding a new bool field to the ViewModel. Since it contains an IList<Employee> in this example, it means creating another EmployeeWithCertificateEligibility class, or better, having separate lists for eligible and ineligible employees. It's somewhat common though to have business logic spill into the view, sometimes in form of an HtmlHelper extension method.

Edit: You compare it to the "initial classic asp implementation". That can mean three things: Classic ASP, ASP.net WebForms or ASP.net MVC with the WebForms/ASPX view engine. My example concerns the first two cases. If you already know the whole MVC stuff and just wonder about the differences between the Webforms and Razor View Engine: Conceptually they are the same, Razor is just a lot less verbose and cleaner.

Answer 2

It's all how you use it.

The main advantage I see of Razor is it that it allows a developer to be more compact and expressive with their layout much like Spark or NHaml.

Instead of writing:

<% Foreach(var x....) { %>
<li><%=x.PropertyName%> (<%=x.AnotherProperty%>)</li>
<% } </%>

You can write it in a more fluid way:

@foreach(var x...) {
<li>@x.PropertyName (@x.AnotherProperty)</li>
}

It's easier to read, flows more nicely and in more complicated cases can be less code.

The reality is that Razor and even classic WebForms you could mix your code and markup together.

It's up to the coder to know when it's a good thing or a bad thing to do.

Is it bad to sprinkle a bit of logic into the view. Perhaps not. Is it bad to write your entire logic into the View most likely yes. What if it's a simple two page app vs. an enterprise application..... I think you get my drift. :-)

Here's a nice write up and another of some of the things Razor can do that also makes it more powerful view engine than classic ASP.

A parting thought. Razor is a view engine. It's designed for making our job easier in crafting the view. It is not designed / meant for coding our entire applications logic. If you are, you are most definitely doing it wrong.

Classic ASP didn't really have an easy distinction of what is view engine vs. what is code.