Jeśli MVC to „Separation of Concerns”, to dlaczego wprowadzono składnię Razor?

Moje pytanie dotyczy wzorca projektowego MVC i Razor Syntax wprowadzonych przez Microsoft.

Podczas nauki wzorca projektowania MVC powiedziano mi, że pomysł opiera się na zasadzie znanej jako Separation of Concerns .

Ale Razor Składnia pozwala nam używać C # w Wyświetleń bezpośrednio.

Czy to nie jest skrzyżowanie obaw?

Łączymy składnię Razor z rozdzieleniem obaw.

Oddzielne obawy związane są ze strukturą kodu.

Możliwość używania C # w widokach nie przeszkadza. Nie ma to nic wspólnego z oddzieleniem obaw jako takich.

Jasne, możesz ustrukturyzować kod w swoim widoku, aby nie był zgodny z separacją problemów, ale co z kodem C # używanym tylko do wyświetlania? Gdzie by to mieszkało?

Zamiast bezpośrednio odpowiadać na pytanie, moja odpowiedź kwestionuje założenia przyjęte w pytaniu. To znaczy założenie, że Razor został zbudowany dla MVC, jest błędne. Pracuję w Microsoft w zespole ASP.NET i mam o tym wiedzę z pierwszej ręki.

Razor nie zaczął się jako silnik podglądu dla MVC. Został stworzony dla stron internetowych ASP.NET , które są prawdopodobnie tak daleko, jak to tylko możliwe, w stronę najmniej podzielonego obszaru zainteresowań spektrum. Został stworzony jako nowoczesna alternatywa dla ASP.NET Web Forms / Classic ASP i oczywiście wielu innych podobnych platform programistycznych dla serwerów. Ideą Razora było stworzenie niemal płynnych przejść między HTML (znacznikami) a C # (kodami).

Dopiero później zespół (w tym ja) zdecydował, że składnia Razor będzie miała sens ze względu na silnik widoku dla MVC, który został napisany przez ten sam zespół.

Jeśli chodzi o to, czy Razor umożliwia, utrudnia, ulepsza lub zmienia koncepcję separacji problemów w ASP.NET MVC, odpowiedź Odeda jest natychmiastowa.

Mylicie „rozdzielenie technologii” z „rozdzieleniem obaw”. Podstawową ideą części „Widok” MVC jest to, że kod w „Widoku” nie wykonuje bezpośrednio żadnego dostępu do danych lub logiki, a pozostawia się to odpowiednio częściom „Model” i „Kontroler”. „Kontroler” przekształca dane, wykonuje niezbędną logikę i kieruje je do właściwego „Widoku”. Widok może także przeprowadzać transformacje danych, ale staram się zachować je czysto kosmetyczne, takie jak wspomniana powyżej transformacja daty.

Mogę wymyślić idealny Don't do itprzykład.

Powiedzmy, że mamy kontroler produktu:

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

Z brzytwą mamy alternatywę

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

i naszym zdaniem:

@model IEnumerable<Product> 

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

Myślę, że to całkiem oczywiste, że drugie rozwiązanie wydaje się tak błędne. Jeśli robisz coś takiego, nie obwiniaj brzytwy - obwiniaj siebie.

I nie zapomnij: Możliwość używania C # w widokach nie jest funkcją brzytwa, było to również możliwe w widokach ASP.NET. Dzięki maszynce do golenia jest to trochę prostsze.

Jeśli szukasz silnika szablonów, który ma więcej szyn, powinieneś spojrzeć na nancy.fx dzięki silnikowi Super simple view.