Confusión entre lógica de vista y lógica de dominio en una aplicación web ASP.NET MVC

Question

Me confunden la lógica de aplicación/dominio y la lógica de la interfaz de usuario. Para ilustrar lo que estoy tratando de definir, describiré un programa imaginario a continuación con fines ilustrativos:

(1) Imagine una aplicación pequeña con un conjunto de 3 menús desplegables en cascada. Al seleccionar un menú desplegable, se activa un JQuery Ajax GET que termina golpeando un controlador MVC, proporcionando el valor seleccionado del menú desplegable previamente seleccionado. El controlador devuelve las opciones permitidas para el siguiente menú desplegable. El javacript (en la vista) organiza estos resultados en un menú desplegable. y así. Por lo tanto, cada vez que selecciona un menú desplegable, el siguiente se llena.

(2) Ahora tirando una llave ... Hay algunas excepciones. Digamos que si el usuario selecciona "FOO" o "BAR" en el primer menú desplegable, entonces el comportamiento cambia, por lo que el segundo menú desplegable se desactiva, y el menú desplegable muestra un cuadro de texto en su lugar.

Mi pregunta es, en el contexto de MVC, ¿cuál es el lugar apropiado para esta lógica de "decisión"? Como el código que es responsable de tomar estas decisiones, como expliqué en (2). El lugar más conveniente que he estado poniendo esto fue justo en el javascript de la vista. Simplemente escribí javascript para probar si el primer cuadro es "FOO" o "BAR", luego desactivo el segundo dropwdown y cambio el tercer menú desplegable para un cuadro de texto. Pero esto no me parece correcto. Porque parece que debería ser una lógica comercial, por lo tanto, el código debería pertenecer a una capa de dominio en algún lugar. Pero eso tampoco se siente del todo bien.

Y siento que voy en círculos. ¿Puede alguien arrojar algo de luz sobre este pequeño diseño?

Answer 1

sin dividir demasiados pelos o acercarse demasiado fanáticos de lo que debe hacerse para mantener el patrón PURE ...

Obviamente, el controlador sabe que este cambio debe ocurrir, ya que manejará ambos casos resultantes (selecciones desplegables o entrada de texto). Entonces poner la lógica relacionada con esto en el Controlador es , no es pecado.

También es igualmente obvio que la Vista debe cambiar la forma en que se muestra dependiendo del contenido del primer menú desplegable. Si bien esta mezcla de comportamientos no es exactamente la mejor experiencia de IU que podría imaginar, si los requisitos lo requieren, entonces la lógica de esto debe existir hasta cierto punto en la IU. Pero, cielos chicos, este es un sitio web del que estamos hablando aquí. ¿Realmente desea eliminar toda la lógica de javascript y moverla a un método de controlador? La Vista está decidiendo cómo mostrar datos, que es su trabajo, por lo que no puede ser un pecado.

La manera real de evitar ser quemado en la hoguera es rediseñando para evitar la controversia en primer lugar. O bien, simplemente codifíquelo y observe sus pésimos requisitos de diseño con respecto a una cerveza.

Answer 2

En esa situación en la que tiene que pasar acciones muy especializadas, debe ponerlo en la lógica en el js como lo ha estado haciendo en su ejemplo desplegable. También siempre querrá poner la validación del lado del servidor para garantizar que sus datos estén limpios.

Con la salida de MVC 2, tienen una gran validación del lado del servidor/cliente de validación. Salida posterior una visión más clara de Scott Gu en esto: MVC 2 Blog Post

Answer 3

Comencemos en el modelo de dominio.Un Modelo de Dominio es una API que modela el Dominio de maneras tecnológicamente neutrales. No sabe nada sobre las tecnologías de visualización como JQuery, HTML o (para el caso) XAML o Windows Forms.

El modelo de dominio contiene clases e interfaces que describen el dominio y le permite modelar los conceptos de dominio de una manera rica y expresiva, sin importar qué tipo de aplicación esté desarrollando.

Teniendo esto en cuenta, es bastante fácil ver que la lógica de visualización que describe no pertenece al Modelo de dominio. Por lo tanto, debe pertenecer a una capa específica de UI.

Puede colocarlo en un módulo UI Logic o junto con su aplicación UI, en su caso una aplicación ASP.NET MVC. Ya sea que exprese la lógica de UI deseada en JavaScript o en el lado del servidor es menos importante.

Personalmente, definiría este lado lógico del servidor en Vistas parciales, pero eso es porque me importa mucho la capacidad de prueba, y sé cómo probaría unitariamente dicho comportamiento (Me han dicho que es posible probar la unidad JQuery código también, pero no tengo idea si eso es cierto o no).

Si alguna vez termina escribiendo otra aplicación basada en el mismo Modelo de Dominio, es muy probable que la lógica de la pantalla sea muy diferente, porque las diferentes tecnologías implican diferentes paradigmas.

Answer 4

Dado su ejemplo, no me importaría esta lógica en el controlador, definitivamente no pertenece al modelo de dominio. Personalmente, me sentiría mejor agarrando la solicitud ajax GET en el controlador y decidir qué producir desde allí con JSON en lugar de hacer toda esa lógica en jQuery (me siento más cómodo en C# y luego en javascript). Habiendo dicho eso, me gustaría mantener mis métodos de acción delgados, así que lo que haría es poner la lógica a la tarea de averiguar qué rellenar los menús desplegables en un método en el conroller y decorarlo con [NonAction].