tutorial - ¿Cuánta lógica está permitida en las vistas ASP.NET MVC?
razor mvc (5)
Aquí hay otra manera de pensar sobre eso. La lógica de presentación va en la vista. La lógica de procesamiento empresarial va en el controlador y la validación de datos va en el modelo. Pero lo que va donde debe ser en última instancia, una guía y no una religión :)
Al observar ejemplos de sitios ASP.NET MVC, veo bastantes ejemplos con lógica incorporada en las vistas, por ejemplo:
<% if (customerIsAllowed)
{ %>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<% } else {%>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<p>nnn</p>
<% } %>
Aunque esto me parece incorrecto, ya que es el tipo de cosas que intentamos evitar en ASP 3.0, incluso he escuchado en algunos podcasts cómo "un poco de lógica a la vista está bien", ya que el resto del framework MVC se está ocupando de la estructura que no teníamos en ASP 3.0.
¿Hay alguna convención de MVC que especifique qué tipo y cuánta lógica se permite en las vistas?
42.
Es una broma :-)
No hay una respuesta establecida para esto, aunque una buena separación de preocupaciones es una mejor práctica generalmente aceptada. El debate en torno a esto puede ser bastante interminable, y conocer la forma correcta de hacerlo para su proyecto particular viene con la experiencia que creo y el poder notar el "olor a código" o cosas que no se sienten bien.
Siempre que la lógica en la vista sea para la presentación (puede colocarla en el código detrás del archivo si no le gusta en el archivo de marcado), entonces está bien. En su ejemplo, el código / lógica es para seleccionar una parte de vista determinada que está bien. La presentación tiene lógica, no necesita ser simplemente HTML.
si la lógica pertenece al formato de la vista, y no da como resultado cambios en entidades o datos, entonces creo que está bien en la vista.
Depende de la razón de la lógica. Si la lógica es elegir una presentación alternativa basada en alguna propiedad que le haya pasado el controlador, probablemente esté bien. Esto le permite un poco de reutilización de vista. En lugar de tener que volver a crear (y repetir) una vista completa para cada privilegio personalizado, puede pasar algunos datos que permiten que la vista se personalice en función de este privilegio.
Pienso en esto como un equilibrio pragmático entre un MVC idealizado y la aplicación estricta de DRY (no te repitas). En algunas situaciones, es más prudente violar uno u otro si no puede alcanzar ambos fácilmente. En el caso donde claramente el modelo y la vista básica son los mismos, poner un poco de lógica en la vista para mantener sus puntos de vista SECOS es razonable.