22

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?

  • 7
    It's worth mentioning that ASP.NET MVC does not actually implement the MVC design pattern. MVC dictates that the model is observed by the view for changes which is clearly not the case in ASP.NET MVC. – Benjamin Gruenbaum Dec 29 '14 at 11:28
  • 11
    It might also help if you changed the way you think about Views. Views are not client-side code. They are server-side templates that, when processed, generate client-side html. And as server-side code, it is perfectly acceptable that there is C# code there. – Eric King Dec 29 '14 at 15:12
  • 6
    @EricKing except for the part where templating systems that allow arbitrary code always lead, via path of least resistance, to bad design, horrible layering violation, and unmaintainability. Unfortunately, it seems to be a lesson that every community has to learn on its own. – hobbs Dec 29 '14 at 17:09
  • 12
    @hobbs Wow, ok. Not in my experience. Certainly not always, and (of course) there's some professional responsibility required on the part of the programmer. I don't blame the tool. – Eric King Dec 29 '14 at 17:32
  • 7
    @BenjaminGruenbaum Isn't like every "MVC"-framework these days different in how they manage interdependencies? To the point where it's no longer productive to talk about The One And Only True MVC-Style, but where it would be more pragmatic to use the term for any system that reasonably partitions responsibility in Models, Views and Controllers however these are interdependent? – Alex Dec 30 '14 at 2:15
66

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?

  • 1
    But C# is server-side language? – John Strowsky Dec 29 '14 at 10:02
  • 6
    @John - so? If you need to format dates for display (and display means client side, always), where would you format them? The model? The controller? Neither. You would do so in the view. – Oded Dec 29 '14 at 10:06
  • 16
    @John - so, your date is stored in the DB, you pass it through the model/controller to your view. You need in there in the HTML, so you would output it somehow to JS to format, instead of directly formatting with C#? Why? Why is that better? Or rather, how is that approach more of a separation of concerns? – Oded Dec 29 '14 at 10:32
  • 25
    @NPSF3000 - a language isn't "server side" or "client side". That's an architectural separation - and possibly one of language implementations (is JavaScript a server side or client side language - remember node.js). – Oded Dec 29 '14 at 12:19
  • 14
    @FreeAsInBeer - this is the kind of logic that belongs on the client side - someone in France would want to see dates (and currency/numbers) formatted differently to someone in the US. The client would "know" best how these should be displayed. This is presentation logic, and as such belongs in the view. – Oded Dec 29 '14 at 14:37
35

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.

  • 2
    Yay, downvote without a comment. I amended my answer to make it clear that I am questioning the assumption made in the original question. As I see it, the question is not directly answerable because it has an invalid premise. – Eilon Dec 29 '14 at 17:19
  • Out of curiosity, were any other templating engines considered for ASP MVC? – NWard Dec 29 '14 at 20:22
  • 2
    @NWard There were a number of 3rd party view engines for ASP.NET MVC at the time, but we didn't consider them too strongly. We felt that Razor was easier to understand (the HTML is HTML, the C# is C#) and also gelled better with the ASP.NET Web Pages project. – Eilon Dec 29 '14 at 21:13
  • 1
    @Alex oh I certainly can't take credit for all of Razor, but I appreciate your comment! – Eilon Dec 30 '14 at 3:59
  • 1
    @ateri After a short while it is the large number at the top left of the answer. – Mark Hurd Dec 31 '14 at 0:24
9

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.

  • this doesn't seem to offer anything substantial over points made and explained in prior answers, particularly this one – gnat Dec 29 '14 at 21:02
  • 4
    +1 Formulated in a concise and clear way and with a different focus of explanation than previous answers. – Alex Dec 30 '14 at 2:26
  • @gnat I just wanted to make it clear where his confusion lay and then quickly explain how the separation of concerns principle applies to the MVC design pattern. Perhaps I should have spent more time on what "separation of concerns" means? – whoisthemachine Dec 31 '14 at 21:02
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.