Если MVC - это разделение интересов, то почему был введен синтаксис Razor?

Мой вопрос связан с шаблоном проектирования MVC и синтаксисом Razor, представленным Microsoft.

При изучении шаблона проектирования MVC мне сказали, что идея основана на принципе, известном как разделение проблем .

Но Razor Syntax позволяет нам использовать C # в Views напрямую.

Разве это не пересечение проблем?

Вы смешиваете синтаксис Razor с разделением интересов.

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

Возможность использования 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, ответ Одеда очевиден .

Вы путаете «разделение технологий» с «разделением интересов». Основная идея, стоящая за частью «View» MVC, заключается в том, что код в «View» не выполняет непосредственный доступ к данным или тяжелую логику, а скорее остается за частями «Model» и «Controller» соответственно. «Контроллер» преобразует данные, выполняет любую необходимую логику и направляет их в правильный «Вид». Представление также может выполнять преобразования данных, но я склонен сохранять их чисто косметическими, такими как преобразование даты, упомянутое выше.

Я могу придумать идеальный 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 с супер простым механизмом просмотра.