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

22

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?

John Strowsky
fuente
77
Vale la pena mencionar que ASP.NET MVC en realidad no implementa el patrón de diseño MVC. MVC dicta que la vista observa cambios en el modelo, lo que claramente no es el caso en ASP.NET MVC.
Benjamin Gruenbaum
11
También podría ayudar si cambiara su forma de pensar acerca de las Vistas. Las vistas no son código del lado del cliente. Son plantillas del lado del servidor que, cuando se procesan, generan html del lado del cliente. Y como código del lado del servidor, es perfectamente aceptable que haya un código C # allí.
Eric King
66
@EricKing, excepto la parte en la que los sistemas de plantillas que permiten un código arbitrario siempre conducen, a través de la ruta de menor resistencia, a un mal diseño, una violación horrible de las capas y la falta de mantenimiento. Desafortunadamente, parece ser una lección que cada comunidad tiene que aprender por sí misma.
hobbs
12
@hobbs Wow, está bien. No en mi experiencia. Ciertamente, no siempre, y (por supuesto) se requiere cierta responsabilidad profesional por parte del programador. No culpo a la herramienta.
Eric King
77
@BenjaminGruenbaum ¿No es como cada marco "MVC" en estos días diferente en la forma en que manejan las interdependencias? Hasta el punto en que ya no sea productivo hablar sobre The One And Only True MVC-Style, pero donde sería más pragmático usar el término para cualquier sistema que razonablemente reparta la responsabilidad en Modelos , Vistas y Controladores, sin embargo, estos son interdependientes.
Alex

Respuestas:

66

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?

Oded
fuente
1
¿Pero C # es lenguaje del lado del servidor?
John Strowsky
66
@John - ¿y qué? Si necesita formatear fechas para la visualización (y la visualización significa del lado del cliente, siempre), ¿dónde las formatearía? ¿El modelo? ¿El controlador? Ninguno. Lo harías en la vista.
Oded
16
@John: por lo tanto, su fecha se almacena en la base de datos, la pasa a través del modelo / controlador a su vista. Necesitas allí el HTML, por lo que lo enviarías de alguna manera a JS para formatear, en lugar de formatear directamente con C #. ¿Por qué? ¿Por qué es eso mejor? O más bien, ¿cómo es ese enfoque más una separación de preocupaciones?
Oded
25
@ NPSF3000: un idioma no es "lado del servidor" o "lado del cliente". Esa es una separación arquitectónica, y posiblemente una de las implementaciones de lenguaje (es JavaScript un lenguaje del lado del servidor o del lado del cliente, recuerde node.js).
Oded
14
@FreeAsInBeer: este es el tipo de lógica que pertenece al lado del cliente: alguien en Francia querría ver las fechas (y la moneda / números) formateadas de manera diferente a alguien en los EE. UU. El cliente "sabrá" mejor cómo se deben mostrar. Esta es la lógica de presentación , y como tal pertenece a la vista.
Oded
35

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.

Eilon
fuente
2
Yay, votar a favor sin un comentario. Modifiqué mi respuesta para dejar en claro que estoy cuestionando la suposición hecha en la pregunta original. A mi entender, la pregunta no responde directamente porque tiene una premisa no válida.
Eilon
Por curiosidad, ¿se consideraron otros motores de plantillas para ASP MVC?
NWard
2
@NWard Había una serie de motores de vista de terceros para ASP.NET MVC en ese momento, pero no los consideramos demasiado. Pensamos que Razor era más fácil de entender (el HTML es HTML, el C # es C #) y también mejoró con el proyecto de páginas web ASP.NET.
Eilon
1
@ Alex, oh, ciertamente no puedo tomar el crédito por todo Razor, ¡pero agradezco tu comentario!
Eilon
1
@ateri Después de un momento es el número grande en la parte superior izquierda de la respuesta.
Mark Hurd
9

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.

whoisthemachine
fuente
Esto no parece ofrecer nada sustancial sobre los puntos señalados y explicados en respuestas anteriores, particularmente este
mosquito
44
+1 Formulado de manera concisa y clara y con un enfoque de explicación diferente al de las respuestas anteriores.
Alex
@gnat Solo quería aclarar dónde estaba su confusión y luego explicar rápidamente cómo se aplica el principio de separación de preocupaciones al patrón de diseño MVC. ¿Quizás debería haber pasado más tiempo en lo que significa "separación de preocupaciones"?
whoisthemachine
0

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.

Jürgen Steinblock
fuente