Lógica empresarial en MVC [cerrado]

184

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.

hmthur
fuente

Respuestas:

173

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.

Barro
fuente
55
Gracias por el ejemplo Para la entrada de correo electrónico del administrador (controlando si se puede eliminar o no), ¿no podemos controlar eso usando nuestro controlador?
hmthur
2
@mud ¿qué pasa si dividimos nuestro modelo en dos capas más, es decir, la capa de servicio y el repositorio ... la capa de servicio es responsable de la lógica de negocios y el repositorio es responsable de la capa de datos ...?
Dragón
3
@PeterMatisko "Los modelos solo deben transportar datos". No estás entendiendo lo que M significa en "MVC". V es puramente presentación. C es pegamento entre presentación y modelo. (De hecho, los "VC" a menudo se consideran juntos como la capa de presentación, y las variaciones populares de MVC como MVVM - Model View Viewmodel - lo hacen aún más claro). La M es todo lo demás : todos los datos y la lógica de su aplicación Puede segregar datos y lógica empresarial dentro de esta capa, y puede llamar a la porción de datos de esta capa su "modelo", pero eso no es a lo que se refiere la "M" en "MVC".
Barro
1
@PeterMatisko "en laravel, la gente arroja todo a los controladores o modelos. Mala arquitectura mala". Mal como ? Se específico. "V" significa "vista". Todo lo que no es una vista necesariamente va en "M" o "C". "MVC no es suficiente, no habla explícitamente sobre la lógica de negocios y dónde ponerlo" Claro que sí. "M" es el modelo de su aplicación, que son sus datos, la lógica de negocios que lo rodea y cualquier otra cosa que no sea presentación. "V" y "C" son capa de presentación, entrada y salida del usuario.
Barro
2
@Mud El problema es que laravel llama a un 'Modelo' solo un soporte de datos. Cuando los tutoriales dicen que Laravel usa MVC y luego ves que 'Modelo' tiene un propósito muy específico, entonces no tienes idea de dónde poner la lógica de negocios. Y el único lugar razonable es el controlador, que no es bueno. No estoy inventando esto, acabo de comentar sobre proyectos típicos de laravel (y tutoriales) que a menudo veo.
Peter Matisko
191

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.

Franco
fuente
10
+1 para enumerar correctamente la diferencia entre la aplicación mvc y n-tier. La mayoría de las aplicaciones empresariales que desarrollo tienen n-tier y usa mvc solo como capa de presentación.
Retired_User
Digamos 1) Ver modelos en MVC (capa de presentación) 2) Algunas tecnologías C # (capa empresarial) para transacciones autorizadas, lógica de reglas comerciales principales. 3) Repositorio y Unidad de trabajo en (Capa de acceso a datos) Por favor, guíe algunas tecnologías (o Patrones recomendados) que se pueden usar para crear una Capa empresarial que debería permitir y exponer el modelo, el repositorio para acceder desde el controlador en la capa de presentación (Superior Capa). Básicamente creo que Agregar, Eliminar, Actualizar y su combinación como lógica de negocios y debería mantenerse en Transacciones. Difunde un poco de luz adicional sobre esto.
Mark Macneil Bikeio
Hola Rahul, si te entiendo correctamente, entonces tienes razón. Las operaciones CRUD son básicamente partes atómicas de las transacciones comerciales. Personalmente, prefiero usar un potente mapeador OR como Hibernate como repositorio en lugar de construir el mío. Esto se debe a que hibernate ya implementa el patrón de unidad de trabajo internamente. También suelo poner transacciones comerciales en servicios comerciales separados.
Frank
Para el modelo de vista, puedo darle el siguiente ejemplo: solo imagen que tiene una GUI con una vista de lista dual. Esta vista de lista dual utiliza un modelo de vista de lista dual como su modelo de datos. Este modelo de datos es solo una composición de dos listas simples. Por lo tanto, el modelo de vista de lista dual depende de la implementación de la capa de presentación, ya que no forma parte de su modelo de dominio, a diferencia de las dos listas simples que se utilizan para crear el modelo de vista. Dependiendo de la GUI que desee crear, hay varios casos en los que es posible que desee vincular un modelo específico de vista a una vista en lugar de su modelo de dominio.
Frank
La parte de reglas de negocio / lógica es un poco difícil de explicar. Para comenzar el procesamiento de datos, debe llamar a un método desde uno de sus servicios. Eso significa que básicamente comienza una transacción. Si este método contiene la lógica empresarial, se llama "secuencia de comandos de transacción". Eso suele ser algo malo, ya que apenas es reutilizable. Sería mejor si este método llama a la lógica de negocios de su modelo de dominio. Esto significa que su modelo de dominio debe diseñarse de manera que pueda contener la lógica empresarial. Este enfoque basado en el dominio no funcionará con un modelo de dominio incompleto o incorrecto.
Frank
73

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:

  • Dominio lógico.
  • 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 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.

Pete
fuente
1
¡Esto es muy cierto! Aquí hay dos modelos: su modelo de vista y su modelo de dominio. Creo que es casi desafortunado que el diseño de los proyectos de MVC lleve a los desarrolladores novatos a creer que simplemente deben meter su código en el Modelo de vista.
Jonathan
1
Encontró su respuesta más aceptable y comprensible. Gracias.
revo
27

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.

deciclón
fuente
16

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.

Treefiddy
fuente
2
La mejor respuesta al respecto. Debería ser votado más alto. La peor respuesta está marcada como aceptada.
Peter Matisko
La mejor respuesta ... sin duda
salman
¿Depende esto del tamaño de los datos y la aplicación? Para una aplicación pequeña, supongo que toda la lógica podría entrar en los modelos sin ninguna confusión. Si es así, ¿cuál es el umbral de tamaño para comenzar a separarse en una capa separada?
mLstudent33
15

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):

  • modelo de presentación : un conjunto de clases que se adapta bien para su uso en la vista (se adapta a la interfaz de usuario / presentación específica),
  • modelo de dominio : la parte del modelo independiente de la interfaz de usuario, y
  • repositorio : la porción del "modelo" que reconoce el almacenamiento.

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".

G. Stoynev
fuente
5

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):ingrese la descripción de la imagen aquí

Alex
fuente
¿Podría aclarar esta afirmación? "Un modelo contiene los datos que provienen de la capa empresarial que pasa a la vista para mostrar"
Anthony Rutledge
2

Q1:

La lógica empresarial se puede considerar en dos categorías:

  1. 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.

  2. 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

Alisa
fuente
0

¿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.

Añil
fuente
-5

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.

Hoven
fuente
Si coloca las reglas de negocio en el controlador y tiene muchas, muchas acciones, ¿va a replicar la regla de negocios muchas, muchas veces? No. Lo separarás en un método auxiliar o una clase de algún tipo. Pon esa "cosa" en el modelo, donde pertenece.
G. Stoynev
3
MVC no es un patrón de aplicación para operaciones de base de datos CRUD (aunque puede usarse de esa manera), por lo tanto, el Modelo no puede ser "código para operaciones de base de datos CRUD". El modelo define las entidades de la aplicación, incluidos los datos y las reglas de negocio. El controlador coordina la interacción entre la vista y el modelo. La vista es la interfaz de usuario que expone el modelo y las operaciones disponibles en los modelos expuestos por el controlador.
Jon Davis