Якщо MVC - це «Розділення турбот», то чому було введено синтаксис Razor?

Моє запитання стосується схеми дизайну MVC та синтаксису Razor, представленого Microsoft.

Під час вивчення схеми дизайну MVC мені сказали, що ідея базується на принципі, відомому як розділення проблем .

Але синтаксис Razor дозволяє нам безпосередньо використовувати C # in Views .

Чи не це перетин проблем?

Ви пов’язуєте синтаксис бритви з відокремленням проблем.

Розмежування проблем пов'язане з тим, як ви структуруєте свій код.

Можливість використання C # у видах цього не заважає. Це не має нічого спільного з відокремленням проблем як таких.

Звичайно, ви можете структурувати код на ваш погляд, щоб він не відповідав роз'єднанню проблем, а як щодо коду C #, який використовується лише для відображення? Де б це жило?

Замість того, щоб безпосередньо відповісти на запитання, моя відповідь ставить під сумнів припущення, зроблене в питанні. Тобто припущення про те, що Razor був побудований для MVC, є невірним. Я працюю в Microsoft над командою ASP.NET і знаю про це з перших рук.

Бритви не почали працювати як двигун перегляду MVC. Він був створений для веб-сторінок ASP.NET , що, мабуть, настільки далеко, наскільки ви можете піти на сторону спектру, що має найменше розмежування. Він був створений як сучасна альтернатива ASP.NET Web Forms / Classic ASP і, звичайно, багато інших подібних систем програмування сервера. Ідея Razor полягала у створенні майже плавних переходів між HTML (розмітка) та C # (код).

Лише пізніше команда (до якої я ввійшов) вирішила, що синтаксис Razor матиме багато сенсу заради механізму перегляду MVC, який написав той самий колектив.

Щодо того, чи дозволяє Razor дозволяє, перешкоджає, вдосконалює чи змінює концепцію розмежування проблем у ASP.NET MVC, відповідь Одіда є місцем.

Ви плутаєте "розділення технологій" з "розділенням проблем". Основна ідея, що стоїть у розділі MVC "Перегляд", полягає в тому, що код у "Перегляді" не виконує жодного доступу до даних або важкої логіки безпосередньо, скоріше, щоб залишити відповідно "Модель" та "Контролер". "Контролер" перетворює дані, виконує будь-яку необхідну логіку та спрямовує їх до правильного "Перегляду". Перегляд також може робити перетворення даних, але я схильний тримати їх виключно косметично, як-от перетворення дати, згадане вище.

Я можу придумати ідеальний Don't do itприклад.

Скажімо, у нас є ProductController:

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

З бритвою у нас є альтернатива

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

і на наш погляд:

@model IEnumerable<Product> 

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

Я думаю, що цілком очевидно, що друге рішення просто почувається таким неправильним. Якщо ви робите щось подібне, не звинувачуйте бритву - звинувачуйте себе.

І не забувайте: вміння використовувати C # у видах не є функцією бритви, можливо, це було можливо і для представлень ASP.NET. З бритвою це просто трохи простіше.

Якщо ви шукаєте шаблон двигуна, який має більше рейок, вам слід поглянути на nancy.fx за допомогою двигуна Super simple view.