¿Por qué colocar la lógica de negocios en el modelo? ¿Qué pasa cuando tengo múltiples tipos de almacenamiento?

La respuesta de ElYusubov principalmente la elimina, la lógica del dominio debe ingresar en el modelo y la lógica de la aplicación en el controlador.

Dos aclaraciones:

• El término lógica de negocios es bastante inútil aquí, porque es ambiguo. Lógica de negocios es un término general para toda la lógica que preocupa a las personas de negocios, separándolas de meros tecnicismos como la forma de almacenar cosas en una base de datos o la forma de mostrarlas en una pantalla. Tanto la lógica de dominio ("una dirección de correo electrónico válida parece ...") como los flujos de trabajo / procesos de negocio ("cuando un usuario se registra, solicite su dirección de correo electrónico") se consideran lógica de negocios, y la primera pertenece claramente a la El modelo y la última es la lógica de aplicación que se incluye en el controlador.
• MVC es un patrón para colocar cosas en una pantalla y permitir que el usuario interactúe con ella, no especifica el almacenamiento en absoluto . La mayoría de los marcos de MVC son marcos de pila completa que van más allá del mero MVC y le ayudan a almacenar sus datos, y como los datos que deben almacenarse generalmente se encuentran en el modelo, estos marcos le brindan formas convenientes de almacenar su modelo. Datos en una base de datos, pero eso no tiene nada que ver con MVC. Idealmente, los modelos deben ser persistentes y el cambio a un tipo diferente de almacenamiento no debería afectar en absoluto al código de modelo. Las arquitecturas completas tienen una capa de persistencia para manejar esto.

Usted y gran parte del mundo de la programación parecen malinterpretar cuáles son los roles de las partes MVC. En resumen, son:

Modelo = lógica de dominio

Ver = lógica de salida

Controlador = lógica de entrada

Esto significa que el modelo es responsable de toda la lógica empresarial: todo lo relacionado con dibujar widgets en una pantalla, manejar una impresora, generar datos como HTML, analizar solicitudes HTTP, etc. modelo.

Sin embargo, muchos de los marcos modernos llamados "MVC" realmente no hacen MVC, o etiquetan incorrectamente sus partes. Muy a menudo, lo que se llama "modelo" es la capa de persistencia del modelo, mientras que la lógica de negocios se asienta en lo que ellos llaman el "controlador"; el controlador real suele ser solo un punto de entrada central con una tabla de enrutamiento y un poco de código en los "controladores" individuales para enviar la entrada que reciben a los procesos de negocio correctos. Lo que estos marcos denominan "vista" es realmente un poco de todo: algo de lógica de presentación (Vista), un poco de manejo y validación de entrada (Controlador) y algo más de lógica empresarial (Modelo). La mayor parte de la vista real suele denominarse "plantillas".

Es posible que también desee leer sobre la arquitectura de múltiples niveles; donde MVC es un tanto unidireccional (el flujo es Controlador - > Modelo - > Vista), Multi-Tier es una cosa bidireccional (Presentación - > Lógica - > Datos - > Lógica - > Presentación ), y bastantes marcos que pretenden hacer MVC en realidad hacen una Presentación a la Vista, Logic to Controller y Data to Model de Tres Niveles.

Para aislar realmente la lógica empresarial y separarla de la infraestructura de la capa de presentación, debe ser encapsulada por los servicios de aplicación. La arquitectura MVC es una forma de implementar la capa de presentación y debe permanecer en ese ámbito, delegando toda la lógica empresarial a estos servicios de aplicación. Piense en los modelos de vista como adaptadores entre la vista y los datos que deben mostrarse o leerse. El controlador media la interacción entre modelos de vista, vistas y servicios de aplicación que albergan la lógica de negocios.

Los servicios de aplicación implementan casos de uso empresarial y se desacoplan de la capa de presentación, ya sea MVC o algo más. A su vez, los servicios de aplicaciones pueden alojar scripts de transacción o diseño controlado por dominio .

Para el almacenamiento, el servicio de aplicaciones puede hacer referencia a un repositorio o cualquier abstracción de un mecanismo de persistencia. Se pueden admitir diferentes implementaciones al abstraer el acceso a los datos en una interfaz. Por lo general, estas abstracciones son leaky y solo son parcialmente transportables a través de implementaciones y con frecuencia es un intento inútil de lograr una portabilidad total .

ACTUALIZAR

Mi sugerencia se basa en la arquitectura hexagonal . En una arquitectura hexagonal, su modelo de dominio (lógica de negocios) está en el núcleo. Este núcleo está encapsulado por servicios de aplicaciones que actúan como una fachada . Los servicios de aplicación son clases simples que tienen métodos correspondientes a casos de uso en su dominio. Para una discusión en profundidad sobre los servicios de aplicaciones, eche un vistazo a Servicios en Diseño impulsado por el dominio . El ejemplo de código contiene un PurchaseOrderService que es un servicio de aplicación para un dominio de compra. (Tenga en cuenta que un servicio de aplicación no implica el uso de diseño controlado por dominio).

En una arquitectura hexagonal, una capa de presentación MVC es un adaptador entre su modelo de dominio (lógica de negocios) y una GUI. El modelo de dominio no es consciente de la capa de presentación, pero la capa de presentación es consciente del modelo de dominio.

Esta solución ciertamente tiene partes móviles que una solución que coloca la lógica de negocios en el controlador y usted debe sopesar los inconvenientes y los beneficios. La razón por la que lo sugiero es porque prefiero mantener la lógica empresarial desconectada de la capa de presentación para combatir la complejidad. Esto se vuelve más importante a medida que la aplicación crece.

Depende de lo que entendemos por lógica empresarial. Cualquier "lógica" que dé sentido a los contenidos del modelo debe estar en el modelo. En la pregunta vinculada, la respuesta más votada parece definir "lógica de negocios" como algo relacionado con los datos; ¡Esto tiene sentido desde el punto de vista de que los datos de una empresa son su negocio!

Una vez vi un ejemplo del creador de Rails (creo) que estaba hablando exactamente de esto, sin poner "lógica de negocios" en el modelo. Su ejemplo fue una clase de controlador y un método para el registro y el inicio de sesión de una aplicación: una contraseña proporcionada en texto sin formato se cifró antes de insertarla o consultarla contra el modelo (una base de datos).

No puedo pensar en un mejor ejemplo de algo que no sea la lógica del controlador y que pertenezca directamente al modelo.

El modelo podría ser una interfaz para miles de almacenes de datos, aliviando las preocupaciones de portabilidad. Es aquí donde uno puede encontrar confusión sobre si la interfaz del modelo es el "controlador".

En términos generales, el controlador vincula el modelo y la vista (que son la carne y la papa de la aplicación). En el desarrollo de Cocoa puede ser simplista hasta el punto en que el controlador se maneja a través de la GUI de XCode (objetos del controlador y encuadernaciones.)

La sección de "Patrones de diseño" de GoF en MVC, citada a la ligera:

  

La tríada MVC de clases se usa para construir interfaces de usuario en Smalltalk-80. El modelo   es el objeto de la aplicación, la vista es la presentación de la pantalla y el controlador define   la forma en que la interfaz de usuario reacciona a la entrada del usuario. MVC desacopla vistas y modelos estableciendo una   Suscribir / notificar protocolo entre ellos. El siguiente diagrama muestra un modelo y tres   puntos de vista. Hemos dejado de lado los controladores para simplificar.

MVC tiene que ver con las interfaces de usuario. El enfoque está en el modelo y la vista: definir y mostrar datos. Tenga en cuenta el "protocolo de suscripción / notificación": aquí es donde entra su controlador. Puede crear todas las vistas que desee; siempre que se adhieran al protocolo, nunca tendrás que tocar el modelo o el controlador.

Si está hablando específicamente de desarrollo web, en mi humilde opinión muchos de los marcos web populares son rápidos y sueltos con el término MVC y sus definiciones de componentes.