He creado una aplicación MVC Java 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 en su mayoría de naturaleza numérica.
Ahora que los datos numéricos 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 calculados 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 los datos que pongo en la base de datos como un registro, sobre los que trabajé realizando cálculos. 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 debería escribir el código para este cálculo de fondo? Como son las reglas y la lógica empresarial, ¿debería ponerlo en nuevos archivos JavaBeans?
Comentarios
- posible duplicado de Permanecer orientado a objetos y comprobable mientras se trabaja con una base de datos
- La lógica empresarial es un alias de un tipo en su equipo / departamento a quien le pregunta cómo hacer / operar en un modelo. Esa ‘ es la razón por la que la lógica empresarial se puede almacenar en una clase separada denominada Lógica empresarial. Lo mismo se aplica a Presentation Logic, que es sinónimo de un diseñador que responde a sus preguntas sobre cómo formatear o mostrar los componentes de la interfaz de usuario. También puede haber una lógica de desarrollador (preguntas que usted mismo hace y responde por sí mismo o pregunta a sus colegas) que representa un conocimiento sobre cómo crear y conectar los componentes de un programa.
Respuesta
La lógica empresarial debe colocarse en el modelo , y deberíamos apuntar a modelos gordos y controladores .
Como punto de partida, debemos partir de 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 en el modelo.
En el modelo, podemos crear fácilmente helper / clases de servicio donde se pueden validar las reglas de negocio o cálculos de la aplicación.
resumen
-
El controlador es para lógica de aplicación. La lógica que es específica de cómo su aplicación quiere interactuar con el » dominio de conocimiento » al que pertenece.
-
El modelo es para una lógica que es independiente de la aplicación . Esta lógica debe ser válida en todas las aplicaciones posibles del » dominio de conocimiento » al que pertenece.
-
Por lo tanto, es lógico colocar todas las reglas comerciales en el modelo.
Comentarios
- buena respuesta clara y concisa ..
- @Yusubov, por favor, ¿podría explicarme la diferencia entre la lógica de la aplicación y la lógica empresarial?
- @Moh, en resumen, estas son palabras de moda para ayudar describir los niveles de tecnología en una aplicación. La lógica empresarial es básicamente reglas del sistema de acuerdo con especificaciones funcionales. Por ejemplo, el Objeto A de tipo B debe tener atribuidos C y D, pero no E. La lógica de aplicación es más una especificación técnica, como usar servlets Java y OJB para persistir en una base de datos Oracle.
- Por favor amplíe 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] - Si entendí bien, el artículo mencionado se refiere a la ‘ lógica de aplicación ‘ como una ‘ lógica empresarial ‘. Por lo tanto, cualquier cosa que se refiera a la lógica empresarial no debe colocarse en el controlador o en la vista.
Responder
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 terminarlo.
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 comercial 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 en god models, sabiendo demasiado. Y esto se convertirá rápidamente en un gran lío que es difícil de probar y mantener. Entonces, en ese caso, es beneficioso poner la lógica en una capa separada.
Cuando decida acerca de la abstracción, siempre tenga en cuenta la complejidad y los propósitos de su aplicación, y evite la ingeniería excesiva. Para aplicaciones triviales / pequeñas, la introducción de más capas de las necesarias aumenta la complejidad en lugar de reducirla.
Robert Martin (tío Bob) tiene una buena publicación de blog sobre este tema: La arquitectura limpia.
Comentarios
- la pregunta era específica para MVC. La lógica empresarial siempre debe estar en el modelo. El controlador es solo un adaptador.
- MVC es uno de los términos más sobrecargados de la industria. No ‘ no quiero meterme en las peculiaridades de este término, ya que merece un libro. Simplemente, usar MVC no ‘ t implica que debe poner todas las lógicas en los modelos.
- 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. - Si pones toda la lógica en el modelo, terminarás con miles de líneas de desorden insostenible. Estado allí. ‘ no es un pecado tener clases de utilidad y una capa de servicio.
- Creo que a lo que se refería jgauffin 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 empresarial pertenece al » modelo «, pero el » modelo » puede abarcar varias clases y capas, incluidas » clases de servicios públicos » y » una capa de servicio » . Para decirlo de otra manera, no ‘ diríamos que la capa de servicio es parte del controlador o vista, por lo tanto, el mejor ajuste es el modelo.
Respuesta
Poner la lógica empresarial dentro del modelo puede parecer la mejor manera de hacerlo. El controlador recibe una llamada de la aplicación web remota. El controlador del servicio web MVC toma la llamada y redirige la ejecución a un método en BL. Ahora, Business Logic se puede incluir en el «Modelo», pero también se puede colocar en alguna otra carpeta, por ejemplo, «Business Logic» . Por lo tanto, no existe una regla estricta sobre dónde estará la lógica empresarial.
He estado usando un servicio web creado en MVC 3.0 y el contenedor de la lógica empresarial es el MVC MODEL .
Comentarios
- 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 empresarial. Como ejemplo simple, creo que es un gran fracaso del enfoque de ASP.NET ‘ para la validación 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 en la que no debería requerirse FirstName? Una capa de lógica empresarial debe consumir el modelo y determinar las acciones adecuadas para él.