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?

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.

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.

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 .