Cuando las reglas comerciales afectan la presentación en MVC

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

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

Por ejemplo, volviendo a mi aplicación de biblioteca inexistente, un bibliotecario está escaneando los 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 en función de ciertas condiciones.

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

Pero los empleados que NO tienen seguridad para hacer esto deberían 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 empresarial . 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 sea innecesario, etc.

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

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

1. Haga que la vista misma verifique la regla de negocio y desactive 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 verifique la regla de negocio.

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

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

5. Usar un ViewModel comprueba la regla empresarial y establece información que indica que el campo está habilitado.

Las opciones 1 y 2 hacen que la capa de presentación tenga que hacer la validación de las reglas de negocio, y eso confunde las cosas.

La opción 3 provocará la duplicación de esfuerzos, ya que ahora tiene dos vistas definidas.

Las opciones 4 y 5 requieren que la capa de presentación sepa que el campo PODRÍA estar habilitado o deshabilitado, pero no POR QUÉ. Creo que me gustan 4 o 5 mejor.

¿Hay otras opciones en las que no estoy pensando?

Creo que su opción número 5 es la mejor, pero con algunos pequeños ajustes:

Su ViewModeldebe tener una propiedad que indica si los datos se pueden actualizar, o no. Quizás una propiedad booleana "CanOverrideLateFine".

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

El Viewinspeccionará la propiedad "CanOverride" y determinar cómo se procesa de forma adecuada para el usuario. Se puede ser tan simple como la activación o desactivación de un campo de formulario, pero puede ser algo completamente diferente (tal vez ni siquiera reproducir el campo, o el suministro de un elemento visual completamente diferente).