¿Dónde poner la lógica empresarial en el diseño MVC?

He creado una aplicación Java MVC simple que agrega registros a través de formularios de datos a una base de datos.

Mi aplicación recopila datos, también los valida y los almacena. Esto se debe a que los datos se obtienen en línea de diferentes usuarios. los datos son principalmente de naturaleza numérica.

Ahora en los datos numéricos que se almacenan en la base de datos (servidor SQL), quiero que mi aplicación realice cálculos y muestre los resultados. El usuario no está interesado en cómo se realizan los cálculos, por lo que deben encapsularse. El usuario solo debe poder ver los datos computados simples (por ejemplo, los datos de la columna A menos los datos de la columna B divididos por los datos de la columna C). Sé cómo escribir procedimientos almacenados para el mismo, pero quiero una aplicación de tres niveles.

Quiero que los datos que puse en la base de datos como un registro, trabajen realizando cálculos en él. Los datos originales no deben verse afectados, mientras que los nuevos datos, después de los cálculos, deben almacenarse como un nuevo registro de entidad en la base de datos.

¿Dónde debo escribir el código para este cálculo de fondo? Como son las reglas y la lógica de negocios, ¿debería ponerlo en nuevos archivos JavaBeans?

— BriskLabs Pakistan
fuente

posible duplicado de Staying OO y Testable mientras se trabaja con una base de datos

— mosquito

Respuestas:

La lógica de negocios debe colocarse en el modelo , y debemos apuntar a modelos gordos y controladores flacos .

Como punto de partida, debemos comenzar desde la lógica del controlador. Por ejemplo: en la actualización , su controlador debe dirigir su código al método / servicio que entrega sus cambios al modelo.

En el modelo, podemos crear fácilmente clases auxiliares / de servicio donde se puedan validar las reglas o cálculos comerciales de la aplicación .

Un resumen conceptual

El controlador es para la lógica de la aplicación. La lógica específica de cómo su aplicación quiere interactuar con el "dominio del conocimiento" al que pertenece.
El modelo es para lógica que es independiente de la aplicación . Esta lógica debería ser válida en todas las aplicaciones posibles del "dominio del conocimiento" al que pertenece.
Por lo tanto, es lógico colocar todas las reglas de negocio en el modelo.

— EL Yusubov
fuente

buena respuesta clara y concisa ..

— hanzolo

@Yusubov, ¿podría explicarme la diferencia entre la lógica de la aplicación y la lógica de negocios

— Mohamad

@Moh, en resumen, estas son palabras de moda para ayudar a describir los niveles de tecnología en una aplicación. La lógica de negocios es básicamente reglas del sistema de acuerdo con especificaciones funcionales. Por ejemplo, el Objeto A de tipo B debe haber atribuido C y D, pero no E. Application Logic es más una especificación técnica, como el uso de servlets Java y OJB para persistir en una base de datos Oracle.

— EL Yusubov

¿Podría explicar estas palabras:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

Si entendí correctamente, el artículo mencionado se refiere a la "lógica de la aplicación" como una "lógica de negocios". Por lo tanto, cualquier cosa que se refiera a la lógica empresarial no debe colocarse en el controlador o la vista.

— EL Yusubov

Como siempre, depende de la complejidad del proyecto.

En aplicaciones triviales, donde la complejidad del modelo de dominio es relativamente pequeña, puede poner la lógica en los modelos y llamarlo un día.

Sin embargo, para aplicaciones no triviales con modelos complejos y muchas reglas comerciales, es mejor separar las cosas un poco más.

Si coloca la lógica de negocios que involucra más de un modelo en un modelo, está introduciendo un acoplamiento estrecho entre esos modelos. A medida que las aplicaciones continúan creciendo, estos modelos tienden a convertirse god models, sabiendo demasiado. Y esto rápidamente se convertirá en un gran desastre que es difícil de probar y mantener. Entonces, en ese caso, es beneficioso colocar la lógica en una capa separada.

Al decidir sobre la abstracción, siempre tenga en cuenta la complejidad y los propósitos de su aplicación, y evite el exceso de ingeniería. Para aplicaciones triviales / pequeñas, la introducción de más capas de las que necesita aumenta la complejidad en lugar de reducirla.

Robert Martin (tío Bob) tiene una buena publicación de blog sobre este tema: The Clean Architecture.

— Hakan Deryal
fuente

La pregunta era específica para MVC. La lógica de negocios siempre debe estar en el modelo. El controlador es solo un adaptador.

— jgauffin

MVC es uno de los términos más sobrecargados en la industria. No quiero entrar en las peculiaridades de este término, ya que garantiza un libro. Simplemente, usar MVC no implica que deba poner todas las lógicas en los modelos.

— Hakan Deryal

A partir de la definición de Steve Burbeck (equipo de Smalltalk):

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Esa es una definición de adaptador.

— jgauffin

Si pones toda la lógica en el modelo, terminarás con miles de líneas de desorden imposible de mantener. Estado allí. No es pecado tener clases de utilidad y una capa de servicio.

— asthasr

Creo que a lo que jgauffin se refería es que la pregunta es específica para MVC. Si aceptamos ver el sistema desde la perspectiva MVC y solo desde la perspectiva MVC, entonces sí, toda la lógica de negocios pertenece al "modelo", pero el "modelo" puede abarcar múltiples clases y capas, incluidas las "clases de utilidad" y "una capa de servicio". Para decirlo de otra manera, no diríamos que la capa de servicio es parte del controlador o la vista, por lo tanto, el mejor ajuste es el modelo.

— DavidS

Poner la lógica de negocios dentro del modelo puede parecer la mejor opción. El controlador recibe una llamada de la aplicación web remota. El controlador en el servicio web MVC toma la llamada y redirige la ejecución a un método en BL. Ahora, Business Logic puede estar contenido en el 'Modelo', pero también puede ubicarse en otra carpeta, por ejemplo, 'Business Logic' . Por lo tanto, no existe una regla estricta sobre dónde va a estar la lógica de negocios.

He estado utilizando un servicio web basado en MVC 3.0 y el contenedor de la lógica empresarial es el MODELO MVC .

— Monty Python
fuente

Estoy de acuerdo. Obtiene una aplicación mucho más flexible cuando su modelo es simplemente una estructura de datos sobre la que actúan otras clases de lógica de negocios. Como un simple ejemplo, creo que es un gran fracaso del enfoque de validación de ASP.NET mediante el uso de atributos. Si anoto la propiedad FirstName de una persona con el atributo Required, ¿qué sucede si creo una vista de administrador donde FirstName no debería ser requerido? Una capa de lógica de negocios debería consumir el modelo y determinar las acciones apropiadas para él.

— xr280xr