Tengo 2 preguntas:
Q1. ¿Dónde se encuentra exactamente la "lógica de negocios" en el patrón MVC? Estoy confundido entre Modelo y Controlador.
Q2 ¿Es "lógica de negocios" lo mismo que "reglas de negocios"? Sí no, ¿Cuál es la diferencia?
Sería genial si pudieras explicar con un pequeño ejemplo.
Respuestas:
Las reglas de negocio 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 notifica al modelo que elimine la entrada N, luego notifica la vista que el modelo ha cambiado.
Quizás el correo electrónico del administrador nunca debe eliminarse de la lista. Esa es una regla de negocios, que el conocimiento pertenece al modelo. La vista puede representar en última instancia esta regla de alguna manera, tal vez el modelo expone una propiedad "IsDeletable" que es una función de la regla empresarial, de modo 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 el guardián de sus datos. Debería poder probar su lógica empresarial sin tocar la interfaz de usuario.
Puño de todos:
creo que estás 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 superponer su aplicación.
Puede ser útil si ve MVC más como una extensión de la capa de presentación.
Si coloca el código de no presentación dentro del patrón MVC, muy pronto podría terminar en un diseño complicado.
Por lo tanto, sugeriría que coloque su lógica empresarial en una capa empresarial separada.
Solo eche un vistazo a esto: artículo de Wikipedia sobre arquitectura multinivel
Dice:
Hoy en día, MVC y un modelo similar de vista de presentador (MVP) 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 (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 su negocio relacionado con la base de datos. reglas 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 interfaz de usuario específica.
Esta técnica es independiente de si utiliza un diseño controlado 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 usar una capa empresarial simple que no sea DDD (una capa empresarial sin lógica de dominio) y una capa de datos simple que escribe directamente en una base de datos específica.
Incluso podría soltar 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 independiente de los controles utilizados. La capa empresarial también puede tener un modelo, llamado "modelo de dominio". Este suele ser el caso cuando decide adoptar un enfoque basado en 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 generalmente llama a la capa empresarial en 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.
La pregunta es: ¿cómo encaja esto en el concepto MVC?
Respuesta -> ¡No lo hace!
Bueno, sí, pero no del todo.
Esto se debe a que MVC es un enfoque que se desarrolló a fines de la década de 1970 para el lenguaje de programación Smalltalk-80. En ese momento, las GUI y las computadoras personales eran bastante poco comunes y ni siquiera se había inventado la red mundial. La mayoría de los lenguajes de programación e 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 la década de 1970.
Debes tener eso en cuenta cuando hables de MVC.
Martin Fowler ha escrito un muy buen artículo sobre MVC, MVP y las GUI de hoy.
El término lógica empresarial no es, en mi opinión, una definición precisa. Evans habla en su libro, Domain Driven Design, sobre dos tipos de lógica de negocios:
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 van necesariamente al mismo lugar.
La lógica de dominio es la lógica que corresponde al dominio real. Entonces, si está creando una aplicación de contabilidad, las reglas de dominio serían reglas relacionadas con cuentas, contabilizaciones, impuestos, etc. etc.
Para ambos tipos de aplicaciones, la importación / exportación CSV podría ser relevante, pero las reglas de importación / exportación CSV no tienen nada que ver con el dominio real. Este tipo de lógica es la lógica de la 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 aplicación no necesariamente tiene que colocarse en la capa del modelo. Eso podría colocarse directamente en los controladores, o podría crear una capa de aplicación separada que aloje esas reglas. Lo más lógico en este caso dependería de la aplicación real.
A1 : Business Logic va a Modelparticipar MVC. El papel de Modeles contener datos y lógica de negocios. ControllerPor otro lado, es responsable de recibir las aportaciones de los usuarios y decidir qué hacer.
A2 : A Business Rulees parte de Business Logic. Ellos tienen una has arelación Business Logictiene Business Rules.
Echa un vistazo a Wikipedia entry for MVC. Vaya a Descripción general donde menciona el flujo del MVCpatrón.
También mira Wikipedia entry for Business Logic. Se menciona que Business Logicse compone de Business Rulesy Workflow.
Como han señalado un par de respuestas, creo que hay algunos malentendidos de la arquitectura multinivel vs MVC.
La arquitectura de múltiples niveles implica dividir su aplicación en niveles / capas (por ejemplo, presentación, lógica de negocios, 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 empresarial / las reglas empresariales / el acceso a datos no deben colocarse directamente en Modelos, Vistas o Controladores. Hacerlo sería colocar la lógica empresarial en su capa de presentación y, por lo tanto, reducir la reutilización y el mantenimiento de su código.
El modelo es una opción de elección muy razonable para colocar la lógica empresarial, pero un enfoque mejor / más sostenible es separar su capa de presentación de su capa lógica empresarial y crear una capa lógica empresarial y simplemente llamar a la capa lógica empresarial de sus 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 código que mezcle la lógica empresarial y el acceso a datos en uno de los componentes de MVC, especialmente si la aplicación no se diseñó con varios niveles. Sin embargo, en la mayoría de las aplicaciones empresariales, comúnmente encontrará arquitecturas de varios niveles con una arquitectura MVC en su lugar dentro de la capa de presentación.
Esta es una pregunta contestada, pero daré mi "un centavo":
Las reglas de negocio pertenecen al modelo. El "modelo" siempre consiste en (lógicamente o físicamente separados):
Las reglas de negocio viven en el modelo de dominio, se exponen en una forma adecuada para la presentación al modelo de "presentación" y a veces se duplican (o también se aplican) en la "capa de datos".
No tiene sentido incluir su capa empresarial en el Modelo para un proyecto MVC.
Digamos que su jefe decide cambiar la capa de presentación a otra cosa, ¡estaría jodido! La capa empresarial 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 Person que reside en la capa empresarial y llama a PersonBusiness.SavePerson (p); donde p es la clase Persona. Esto es lo que hago (falta la clase BusinessError pero también iría en BusinessLayer):
Q1:
La lógica empresarial se puede considerar en dos categorías:
Las lógicas de dominio, como los controles en una dirección de correo electrónico (unicidad, restricciones, etc.), obtener el precio de un producto para la factura o calcular el precio total de shoppingCart en función de los objetos de su producto.
Flujos de trabajo más amplios y complicados que se denominan procesos empresariales, como controlar el proceso de registro para el alumno (que generalmente incluye varios pasos y necesita diferentes controles y tiene restricciones más complicadas).
La primera categoría entra en modelo y la segunda pertenece al controlador . Esto se debe a que los casos en la segunda categoría son lógicas de aplicación amplias y ponerlos en el modelo puede mezclar la abstracción del modelo (por ejemplo, no está claro si necesitamos poner esas decisiones en una clase de modelo u otra, ya que están relacionadas ¡a ambos!).
Vea esta respuesta para una distinción específica entre modelo y controlador, este enlace para definiciones muy exactas y también este enlace para un buen ejemplo de Android.
El punto es que las notas mencionadas por "Mud" y "Frank" arriba pueden ser ciertas así como también las de "Pete" (la lógica de negocios se puede poner en modelo o controlador, de acuerdo con el tipo de lógica de negocios).
Finalmente, tenga en cuenta que MVC difiere de un contexto a otro. Por ejemplo, en las aplicaciones de Android, se sugieren algunas definiciones alternativas que difieren de las basadas en la web (consulte esta publicación, por ejemplo).
Q2:
La lógica empresarial es más general y (como "deciclón" mencionado anteriormente) tenemos la siguiente relación entre ellos:
reglas de negocios ics lógicas de negocios
¿Por qué no introduces una capa de servicio? entonces su controlador será delgado y más legible, entonces todas sus funciones de controlador serán acciones puras. puede descomponer la lógica de negocios tanto como lo necesite dentro de la capa de servicio. la reutilización del código es alta. sin impacto en modelos y repositorios.
Modelo = código para operaciones de base de datos CRUD.
Controlador = responde a las acciones del usuario y pasa las solicitudes de recuperación de datos o eliminación / actualización del modelo al modelo, sujeto a las reglas comerciales específicas de una organización. Estas reglas de negocio podrían implementarse en clases auxiliares, o si no son demasiado complejas, solo directamente en las acciones del controlador. El controlador finalmente le pide a la vista que se actualice a sí misma para dar retroalimentación al usuario en forma de una nueva pantalla, o un mensaje como 'actualizado, gracias', etc.
Ver = IU que se genera en función de una consulta en el modelo.
No existen reglas estrictas sobre dónde deben ir las reglas comerciales. En algunos diseños entran en 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.