Saltar al contenido

MVC: ¿Dónde poner la lógica empresarial?

No dejes de divulgar nuestros tutoriales y códigos con tus amigos, ayúdanos a hacer crecer nuestra comunidad.

Solución:

Prefiero poner lógica de dominio en el modelo por un par de razones.

  1. El modelo no debe tener código de interfaz de usuario y, por lo tanto, debe ser más fácil de probar. Siempre que sea posible, me gusta tener un modelo que funcione completamente (lo que significa una cobertura de prueba completa) antes de escribir cualquier código de interfaz de usuario. El controlador puede confiar en que el modelo está haciendo lo correcto y solo se ocupa de las preocupaciones de la interfaz de usuario.

  2. Si coloca la lógica de dominio en un controlador, no es tan fácil de compartir entre diferentes aplicaciones, o incluso entre diferentes controladores.

Me gusta mantener mis modelos limpios, es decir, solo con propiedades y sin lógica comercial. Siempre pienso que es bueno inyectar dependencias en el controlador y estas dependencias contienen la lógica que realizo en mis modelos. Me gusta adherirme al principio de responsabilidad única siempre que sea posible y encuentro que los modelos con toneladas de métodos se hinchan muy rápidamente. Hay pros y contras para ambos, inyectar muchas dependencias tiene una sobrecarga pero permite probar de forma aislada y mantiene las clases simples y terminará teniendo controladores más eficientes. A pesar de que mi lógica no existe realmente en mi modelo como miembros de la clase, sigue siendo una lógica comercial. Tiendo a no tener la lógica empresarial definida en el controlador, ya que burlarse de cosas como el contexto Http es un poco una pesadilla e innecesaria.

los negocio la lógica pertenece al dominio del problema y todo lo que pertenece al dominio del problema va al modelo en MVC.

los controlador debe ser responsable de pasar los datos del modelo a la vista y de la vista al modelo. Por lo tanto, el controlador es el puente entre aquello con lo que interactúa el usuario y cómo el programa modela y almacena el estado del problema. los plomeríapor así decirlo.

los key aquí está la distinción entre la lógica de negocios y la lógica de plomería. En mi opinión, lo que hace el controlador de cuentas generado automáticamente es principalmente plomería, no realmente lógica comercial. Tenga en cuenta que la lógica de plomería no es necesariamente corta, por lo que no necesita imponer límites artificiales (como “X número de llamadas como máximo en el controlador”).

Si haces scroll puedes encontrar las notas de otros sys admins, tú aún eres capaz mostrar el tuyo si lo deseas.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *