Cuando las reglas de negocios afectan la presentación en MVC

8

Se supone que el patrón de diseño de MVC lleva a separar las reglas de negocio de la presentación.

Pero a veces las reglas de negocio AFECTAN la presentación. ¿Cuál es la mejor manera de lidiar con esto? ¿Es cuando se debe usar un ViewModel?

Por ejemplo, volviendo a mi aplicación de biblioteca inexistente, un bibliotecario está escaneando libros devueltos. El sistema indica que un libro llega tarde y aplica una multa a ese usuario.

Ciertos empleados pueden tener seguridad para anular esa multa según ciertas condiciones.

La capa de presentación de la aplicación de mi biblioteca deberá permitir que el empleado establezca la multa en 0, o hacer clic en un botón para anular la multa.

Pero los empleados que NO tienen seguridad para hacer esto deben ver la tarifa como una entrada deshabilitada o tal vez de solo lectura.

Tenga en cuenta que la seguridad puede no ser la única regla de negocios . Esto es solo un ejemplo. Por ejemplo, mi aplicación puede tener información de configuración configurada en algún lugar que hace que un campo en una pantalla se vuelva innecesario, etc.

Si bien el código podría permitir que cualquiera cambie la multa y luego mostrar un mensaje de validación, no es una buena experiencia para el usuario.

¿Qué es una buena práctica para lograr esto? Las opciones que se me ocurren (usando ASP.NET MVC) son:

  1. Haga que la vista verifique la regla de negocios y deshabilite o habilite el campo.

  2. Use una función HTMLHelper que implemente la presentación para el campo fino y haga que esa función auxiliar compruebe la regla de negocios.

  3. Haga que el controlador verifique la regla de negocios y use una vista diferente.

  4. Haga que el controlador verifique la regla de negocios y establezca una propiedad en el ViewBag que indique si el campo está habilitado.

  5. Use un ViewModel verifica la regla de negocios y establece la información que indica que el campo está habilitado.

Opciones 1 & 2 hace que la capa de presentación tenga que hacer la validación de las reglas de negocios, y eso confunde las cosas.

La opción 3 causará una duplicación de esfuerzos ya que ahora tiene dos vistas definidas.

Opción 4 & 5 requiere que la capa de presentación sepa que el campo PODRÍA estar habilitado o inhabilitado, pero no POR QUÉ. Creo que me gustan 4 o 5 mejores.

¿Hay otras opciones en las que no estoy pensando?

    
pregunta scott.korin 18.02.2012 - 17:11

1 respuesta

3

Creo que tu opción número 5 es la mejor, pero con algunos ajustes leves:

Su ViewModel debería tener una propiedad que indique si los datos pueden actualizarse o no. Tal vez una propiedad booleana "CanOverrideLateFine".

Lo que sea que esté creando el ViewModel (su Controlador, o más probablemente un servicio comercial al que su Controlador delega) es responsable de evaluar las reglas comerciales y establecer esa propiedad. No el ViewModel en sí.

El View luego inspeccionará la propiedad "CanOverride" y determinará cómo renderizar adecuadamente para el usuario. puede ser tan simple como habilitar o deshabilitar un campo de formulario, pero puede ser algo completamente diferente (tal vez ni siquiera representar el campo, o suministrar un elemento visual completamente diferente).

    
respondido por el Eric King 18.02.2012 - 21:58

Lea otras preguntas en las etiquetas