design-patterns - pattern - mvc example java
Lógica empresarial en MVC (9)
Como han señalado un par de respuestas, creo que hay algunos malentendidos entre la arquitectura multi-nivel vs MVC.
La arquitectura de niveles múltiples implica dividir su aplicación en niveles / capas (por ejemplo, presentación, lógica comercial, acceso a datos)
MVC es un estilo arquitectónico para la capa de presentación de una aplicación. Para aplicaciones no triviales, la lógica de negocios / reglas comerciales / acceso a datos no debe colocarse directamente en Modelos, Vistas o Controladores. Hacerlo sería colocar la lógica comercial en la capa de presentación y, por lo tanto, reducir la reutilización y la capacidad de mantenimiento de su código.
El modelo es una elección muy razonable para ubicar la lógica empresarial, pero un enfoque mejor / más sostenible es separar la capa de presentación de la capa de lógica de negocios y crear una capa de lógica de negocios y simplemente llamar a la capa de lógica de negocios de los modelos cuando sea necesario. La capa de lógica de negocios a su vez llamará a la capa de acceso a datos.
Me gustaría señalar que no es raro encontrar un código que combine la lógica comercial y el acceso a los datos en uno de los componentes de MVC, especialmente si la aplicación no se diseñó utilizando varios niveles. Sin embargo, en la mayoría de las aplicaciones empresariales, comúnmente encontrará arquitecturas de múltiples capas con una arquitectura MVC en su lugar dentro de la capa de presentación.
Tengo 2 preguntas:
Q1. ¿Dónde exactamente se encuentra la "lógica comercial" en el patrón MVC? Estoy confundido entre Modelo y Controlador.
Q2. ¿La "lógica comercial" es lo mismo que "reglas comerciales"? Sí no, ¿Cuál es la diferencia?
Sería genial si pudieras explicar con un pequeño ejemplo.
En mi opinión, el término lógica de negocios no es una definición precisa. Evans habla en su libro, Domain Driven Design, sobre dos tipos de lógica empresarial:
- Lógica de dominio.
- Lógica de aplicación.
Esta separación es en mi opinión mucho más clara. Y al darse cuenta de que existen diferentes tipos de reglas comerciales, también se da cuenta de que no todas necesariamente van al mismo lugar.
La lógica del dominio es la lógica que corresponde al dominio real. Entonces, si está creando una aplicación de contabilidad, entonces las reglas de dominio serían reglas con respecto a cuentas, publicaciones, impuestos, etc. En una herramienta ágil de planificación de software, las reglas serían similares al cálculo de fechas de lanzamiento basadas en velocidad y puntos de historia en la acumulación, etc.
Para ambos tipos de aplicación, la importación / exportación de CSV podría ser relevante, pero las reglas de importación / exportación de CSV no tienen nada que ver con el dominio real. Este tipo de lógica es lógica de aplicación.
La lógica del dominio ciertamente entra en la capa del modelo. El modelo también correspondería a la capa de dominio en DDD.
Sin embargo, la lógica de la aplicación no necesariamente debe colocarse en la capa del modelo. Eso podría colocarse en los controladores directamente, o podría crear una capa de aplicación separada que albergue esas reglas. Lo más lógico en este caso dependerá de la aplicación real.
Esta es una pregunta contestada, pero le daré mi "un centavo":
Las reglas comerciales pertenecen al modelo. El "modelo" siempre consiste en (lógica o físicamente separado):
- modelo de presentación : un conjunto de clases que es muy adecuado para su uso en la vista (se adapta a una interfaz de usuario / presentación específica),
- modelo de dominio : la parte independiente del UI del modelo, y
- repositorio : la parte del "modelo" que tiene en cuenta el almacenamiento.
Las reglas de negocio viven en el modelo de dominio, se exponen en una presentación adecuada al modelo de "presentación" y a veces se duplican (o se imponen) en la "capa de datos".
Las reglas comerciales van en el modelo.
Digamos que estaba mostrando correos electrónicos para una lista de correo. El usuario hace clic en el botón "eliminar" al lado de uno de los correos electrónicos, el controlador le notifica al modelo que elimine la entrada N y luego notifica a la vista que el modelo ha cambiado.
Quizás el correo electrónico del administrador nunca se deba eliminar de la lista. Esa es una regla de negocios, ese conocimiento pertenece al modelo. En última instancia, la vista puede representar esta regla: quizás el modelo exponga una propiedad "IsDeletable" que es una función de la regla comercial, por lo que el botón Eliminar en la vista está deshabilitado para ciertas entradas, pero la regla en sí no está contenida en la vista.
El modelo es en última instancia guardián de sus datos. Debería poder probar su lógica comercial sin tocar la IU en absoluto.
Modelo = código para las operaciones de la base de datos CRUD.
Controller = responde a las acciones del usuario y pasa las solicitudes del usuario para recuperar datos o eliminar / actualizar el modelo, sujeto a las reglas comerciales específicas de una organización. Estas reglas de negocio podrían implementarse en clases de ayuda, o si no son demasiado complejas, solo directamente en las acciones del controlador. El controlador finalmente le pide a la vista que se actualice para dar retroalimentación al usuario en forma de una nueva pantalla, o un mensaje como ''actualizado, gracias'', etc.,
View = UI que se genera en base a una consulta en el modelo.
No existen reglas estrictas con respecto a dónde deberían ir las reglas comerciales. En algunos diseños entran en el modelo, mientras que en otros se incluyen con el controlador. Pero creo que es mejor mantenerlos con el controlador. Deje que el modelo se preocupe solo por la conectividad de la base de datos.
No tiene sentido poner su capa de negocios en el Modelo para un proyecto de MVC.
Diga que su jefe decide cambiar la capa de presentación a otra cosa, ¡estaría jodido! La capa de negocios debe ser un ensamblaje separado. Un modelo contiene los datos que provienen de la capa empresarial que pasa a la vista para mostrar. Luego, en la publicación, por ejemplo, el modelo se une a una clase Persona que reside en la capa empresarial y llama a PersonBusiness.SavePerson (p); donde p es la clase de persona. Esto es lo que hago (falta la clase BusinessError, pero también iría en BusinessLayer):
Puño de todos:
Creo que está mezclando el patrón MVC y los principios de diseño basados en n niveles.
El uso de un enfoque MVC no significa que no deba aplicar capas a su aplicación.
Puede ser útil si ve MVC más como una extensión de la capa de presentación.
Si coloca código de no presentación dentro del patrón MVC, muy pronto podría terminar en un diseño complicado.
Por lo tanto, sugiero que coloque su lógica de negocios en una capa de negocios separada.
Solo eche un vistazo a esto: artículo de Wikipedia sobre arquitectura multitier
Dice:
Hoy, MVC y modelo-vista-presentador (MVP) similar son patrones de diseño de Separación de preocupaciones que se aplican exclusivamente a la capa de presentación de un sistema más grande.
De todos modos ... cuando se habla de una aplicación web empresarial, las llamadas desde la interfaz de usuario a la capa de lógica de negocios deben colocarse dentro del controlador (presentación).
Esto se debe a que el controlador realmente maneja las llamadas a un recurso específico, consulta los datos haciendo llamadas a la lógica de negocios y vincula los datos (modelo) a la vista apropiada.
Mud te dijo que las reglas de negocio entran en el modelo.
Eso también es cierto, pero mezcló el modelo (de presentación) (la ''M'' en MVC) y el modelo de capa de datos de un diseño de aplicación basado en niveles.
Por lo tanto, es válido colocar las reglas comerciales relacionadas con la base de datos en el modelo (capa de datos) de su aplicación.
Pero no debe colocarlos en el modelo de su capa de presentación estructurada MVC, ya que esto solo se aplica a una IU específica.
Esta técnica es independiente de si utiliza un diseño impulsado por dominio o un enfoque basado en script de transacción.
Déjame visualizar eso para ti:
Capa de presentación: Modelo - Vista - Controlador
Capa empresarial: lógica de dominio - lógica de aplicación
Capa de datos: repositorios de datos: capa de acceso a datos
El modelo que ve arriba significa que tiene una aplicación que usa MVC, DDD y una capa de datos independiente de la base de datos.
Este es un enfoque común para diseñar una aplicación web empresarial más grande.
Pero también puede reducirlo para utilizar una capa empresarial simple que no sea DDD (una capa empresarial sin lógica de dominio) y una capa de datos simple que escriba directamente en una base de datos específica.
Incluso podría eliminar toda la capa de datos y acceder a la base de datos directamente desde la capa empresarial, aunque no lo recomiendo.
Ese es el truco ... Espero que esto ayude ...
[Nota:] También debe tener en cuenta el hecho de que hoy en día hay más de un "modelo" en una aplicación. Comúnmente, cada capa de una aplicación tiene su propio modelo. El modelo de la capa de presentación es específico de la vista, pero a menudo es independiente de los controles utilizados. La capa de negocios también puede tener un modelo, llamado "modelo de dominio". Este suele ser el caso cuando decide tomar un enfoque impulsado por el dominio. Este "modelo de dominio" contiene datos y lógica de negocios (la lógica principal de su programa) y generalmente es independiente de la capa de presentación. La capa de presentación normalmente llama a la capa empresarial sobre un determinado "evento" (botón presionado, etc.) para leer o escribir datos en la capa de datos. La capa de datos también puede tener su propio modelo, que generalmente está relacionado con la base de datos. A menudo contiene un conjunto de clases de entidad, así como objetos de acceso a datos (DAO).
La pregunta es: ¿cómo encaja esto en el concepto de MVC?
Respuesta -> ¡No!
Bueno, algo hace, pero no completamente.
Esto se debe a MVC es un enfoque que se desarrolló a finales de 1970 para el lenguaje de programación Smalltalk-80. ¡En ese momento las GUI y las computadoras personales eran bastante poco comunes y la red mundial ni siquiera se había inventado! La mayoría de los lenguajes de programación y IDE actuales se desarrollaron en la década de 1990. En ese momento las computadoras y las interfaces de usuario eran completamente diferentes de las de los años setenta.
Debes tener esto en cuenta cuando hablas de MVC.
Martin Fowler ha escrito un artículo muy bueno sobre MVC, MVP y las GUI de hoy.
Q1:
La lógica de negocios se puede considerar en dos categorías:
Lógicas de dominio como controles en una dirección de correo electrónico (unicidad, restricciones, etc.), obtener el precio de un producto por factura o, calcular el precio total de shoppingCart en función de sus productos.
Flujos de trabajo más amplios y complicados que se llaman procesos de negocios, como controlar el proceso de registro para el estudiante (que generalmente incluye varios pasos y necesita verificaciones diferentes y tiene restricciones más complicadas).
La primera categoría entra en el modelo y la segunda pertenece al controlador . Esto se debe a que los casos en la segunda categoría son amplias lógicas de aplicación y ponerlos en el modelo puede mezclar la abstracción del modelo (por ejemplo, no está claro si tenemos que poner esas decisiones en una clase de modelo u otra, ya que están relacionadas ¡a ambos!).
Vea esta answer para una distinción específica entre modelo y controlador, este link para definiciones muy exactas y también este link para un buen ejemplo de Android.
El punto es que las notas mencionadas por "Mud" y "Frank" arriba pueden ser verdaderas así como también "Pete" (la lógica de negocios puede ponerse en modelo, o controlador, de acuerdo con el tipo de lógica de negocios).
Finalmente, tenga en cuenta que MVC difiere de contexto a contexto. Por ejemplo, en las aplicaciones de Android, se sugieren algunas definiciones alternativas que difieren de las basadas en la web (consulte esta post por ejemplo).
Q2:
La lógica de negocios es más general y (como "deciclón" mencionado anteriormente) tenemos la siguiente relación entre ellos:
reglas comerciales ⊂ lógica de negocios
A1 : Business Logic va a la parte Model en MVC . El rol del Model es contener datos y lógica comercial. Controller otro lado, el Controller es responsable de recibir la entrada del usuario y decidir qué hacer.
A2 : una Business Rule es parte de Business Logic de Business Logic . Ellos tienen has a relación. Business Logic tiene Business Rules .
Eche un vistazo a la Wikipedia entry for MVC . Vaya a Descripción general donde menciona el flujo del patrón MVC .
Consulte también la Wikipedia entry for Business Logic . Se menciona que Business Logic se compone de Business Rules y Workflow .