Si MVC es "Separación de preocupaciones", ¿por qué se introdujo la sintaxis Razor?

Mi pregunta está relacionada con el patrón de diseño MVC y la sintaxis Razor introducida por Microsoft.

Mientras aprendía el patrón de diseño de MVC, me dijeron que la idea se basa en un principio conocido como Separación de preocupaciones .

Pero Razor Syntax nos permite usar C # en Vistas directamente.

¿No es esta intersección de preocupaciones?

Estás combinando la sintaxis de Razor con la separación de preocupaciones.

La separación de preocupaciones tiene que ver con cómo estructura su código.

Ser capaz de usar C # en las vistas no impide eso. No tiene nada que ver con la separación de las preocupaciones como tal.

Claro, puede estructurar el código desde su punto de vista para no cumplir con la separación de preocupaciones, pero ¿qué pasa con el código C # que se usa solo para fines de visualización? ¿Dónde viviría eso?

En lugar de responder directamente a la pregunta, mi respuesta cuestiona la suposición hecha en la pregunta. Es decir, la suposición de que Razor se creó para MVC es incorrecta. Trabajo en Microsoft en el equipo ASP.NET y tengo conocimiento de primera mano de esto.

Razor no comenzó como un motor de visualización para MVC. Fue creado para las páginas web ASP.NET , que probablemente sea lo más lejos que pueda llegar al lado del espectro con las preocupaciones menos separadas. Fue creado como una alternativa moderna a ASP.NET Web Forms / Classic ASP y, por supuesto, a muchos otros marcos de programación de servidores similares. La idea de Razor era crear transiciones casi perfectas entre HTML (marcado) y C # (código).

Solo más tarde el equipo (que me incluye a mí mismo) decidió que la sintaxis de Razor tendría mucho sentido en aras de un motor de visualización para MVC, que estaba siendo escrito por el mismo equipo.

En cuanto a si Razor permite, obstaculiza, mejora o altera el concepto de separación de preocupaciones en ASP.NET MVC, la respuesta de Oded es acertada.

Estás confundiendo "separación de tecnologías" con "separación de preocupaciones". La idea básica detrás de la parte "Ver" de MVC es que el código en la "Vista" no realiza ningún acceso a datos o lógica pesada directamente, sino que se deja a las partes "Modelo" y "Controlador" respectivamente. El "Controlador" transforma los datos, realiza la lógica necesaria y los dirige a la "Vista" correcta. La vista también puede realizar transformaciones de datos, pero tiendo a mantenerlas puramente cosméticas, como la transformación de fecha mencionada anteriormente.

Puedo pensar en un Don't do itejemplo perfecto .

Digamos que tenemos un ProductController:

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

Con navaja tenemos una alternativa

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

y en nuestra opinión:

@model IEnumerable<Product> 

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

Creo que es bastante obvio que la segunda solución se siente tan mal. Si haces algo como esto, no culpes a la maquinilla de afeitar, cúlpate a ti mismo.

Y no olvide: ser capaz de usar C # en las vistas no es una característica de afeitar, también fue posible con las vistas ASP.NET. Con la maquinilla de afeitar es un poco más simple.

Si está buscando un motor de plantillas que tenga más rieles, debería echar un vistazo a nancy.fx con el motor de visualización Super simple.