If MVC is "Separation of Concerns" then why was Razor Syntax introduced?

Question

My question is related to MVC design pattern and Razor Syntax introduced by Microsoft.

While learning MVC design pattern I was told that the idea is based upon a principle known as Separation of Concerns.

But Razor Syntax allows us to use C# in Views directly.

Isn't this intersection of concerns?

Answer 1

You are conflating the Razor syntax with separation of concerns.

Separation of concerns has to do with how you structure your code.

Being able to use C# in views doesn't prevent that. It has nothing to do with separation of concerns as such.

Sure, you can structure the code in your view to not comply with separation of concerns, but what about C# code that is used for display purposes only? Where would that live?

Answer 2

Rather than directly answer the question, my response questions the assumption made in the question. That is, the assumption that Razor was built for MVC is incorrect. I work at Microsoft on the ASP.NET team and have first-hand knowledge of this.

Razor did not start out as a view engine for MVC. It was created for ASP.NET Web Pages, which is probably as far as you can go towards the least-separated-concerns side of the spectrum. It was created as a modern alternative to ASP.NET Web Forms / Classic ASP and of course many other similar server programming frameworks. The idea of Razor was to create nearly seamless transitions between HTML (markup) and C# (code).

Only later did the team (which includes myself) decide that the Razor syntax would make a lot of sense for the sake of a view engine for MVC, which was being written by the same team.

As to whether Razor enables, hinders, improves, or alters the concept of separation of concerns in ASP.NET MVC, Oded's answer is spot on.

Answer 3

You are confusing "separation of technologies" with "separation of concerns". The basic idea behind the "View" portion of MVC is that code in the "View" is not performing any data access or heavy logic directly, rather that is left to the "Model" and "Controller" portions respectively. The "Controller" transforms the data, performs any necessary logic, and routes it to the correct "View". The view can also do data transformations, but I tend to keep them purely cosmetic, such as the date transform mentioned above.

Answer 4

I can think of a perfect Don't do it example.

Lets say we have a ProductController:

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.Where(x => x.Discontinued).ToList();
        return new ViewResult(products);
    }
}

With razor we have an alternative

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.ToList();
        return new ViewResult(products);
    }
}

and in our view:

@model IEnumerable<Product> 

@foreach (var item in Model.Where(x => x.Discontinued)) {
    ....
}

I think it is pretty obvious that the second solution just feels so wrong. If you do something like this, don't blame razor - blame yourself.

And don't forget: Being able to use C# in views is not a razor feature, it was possible with ASP.NET views, too. With razor it's just a little bit simpler.

If you are searching for a template engine which is more rails like you should take a look at nancy.fx with the Super simple view engine.