¿Dónde está la M en MVC?

14

Estoy tratando de refactorizar mi aplicación en MVC, pero estoy atascado en la parte M.

En una aplicación respaldada por una base de datos, el modelo se implementa en el código de la aplicación, ¿verdad?

Pero entonces, ¿qué hay en la base de datos? ¿No es ese también el modelo?

(No estoy usando la base de datos como un simple almacén de objetos: los datos en la base de datos son un activo empresarial).


fuente
I'm not using the database as a simple object store. Supongo que eso significa algo de lógica empresarial en la base de datos, en forma de procedimientos almacenados. En teoría eso va en contra de MVC, pero en la práctica no importa.
yannis 01 de
@YannisRizos - no es BL en el PP, pero lo que quiero decir con esto es que quiero que los datos en la base de datos para tener una vida y significado más allá de la aplicación.
3
I want the data in the DB to have a life and meaning beyond the application.¿Qué?
yannis 01 de
2
@ YannisRizos: definitivamente agradecería ayuda para refactorizar esa declaración. Los datos son un activo empresarial, ¿verdad? No pertenece a la aplicación, por lo que no se le permite crear un modelo desnormalizado loco que lo haga muy fácil para la aplicación , si eso dificulta la reutilización de los datos de otras aplicaciones. ¿Alguna sugerencia?
1
Eso no será un problema, si hay un formato para cualquier cosa existente que deba compartirse, entonces eso se convierte en parte de los requisitos para el formato de almacenamiento. Cualquier cosa en el futuro que lo necesite en otro formato puede tener una tarea ETL, o transformarla en el DAL.
StuperUser

Respuestas:

46

Sí, tanto el modelo en el código como la base de datos son el "Modelo".

El modelo tiene que ver con lo que su aplicación "ES", y el controlador es lo que "hace". Cualquier código relacionado con la persistencia directa a la base de datos se considera el Modelo.

Nota: MVC es un patrón , así que no lo pienses demasiado. Es fácil lograr que todos los súper hagan MVC de la manera correcta, pero al final del día, ¡es solo una mentalidad! Significa mantener su lógica de negocios fuera de la base de datos y la interfaz de usuario, eso es todo. Antes de MVC, las personas colocaban la lógica de negocios en sus páginas web cuando debería estar en el servidor, o tenían un montón de scripts que se activaban en la base de datos haciendo lógica de negocios junto con el código de persistencia. MVC se creó para que la gente comenzara a pensar de una manera que ayudara a que su código sea reutilizable, por lo que no se deje atrapar demasiado por los detalles.

Ryan Hayes
fuente
15
Entonces, desde la perspectiva de C y V, ¿hay una base de datos que es solo un detalle de implementación de M?
Seguro. Muy bien redactado.
herby 01 de
3
@MattFenwick Desde la perspectiva de C y V, no hay una base de datos. Está utilizando la base de datos como algo más que almacenamiento de datos, en términos de MVC, una base de datos es solo un almacenamiento de datos. Pero eso está perfectamente bien, si se adapta a su aplicación.
Yannis 01 de
55
+1 para "no pienses demasiado en mvc"
Javier
2
"mantenga su lógica de negocios fuera de la base de datos y la interfaz de usuario" - esto
David Murdoch
17

Trygve Reenskaug escribió los documentos iniciales describen el patrón MVC en 1978. El Modelo en su descripción era el modelo de objetos que representa objetos, fenómenos y conceptos del mundo real. En su escenario de una aplicación respaldada por una base de datos, el modelo es una proyección de sus datos. En pocas palabras, el modelo es las clases y sus relaciones que conciernen a su aplicación.

En la práctica, generalmente se usan dos modelos en MVC, el Modelo de dominio (lo que se asigna a su base de datos) y el Modelo de aplicación (también denominado Modelo de vista en la terminología actual). El modelo de aplicación es una proyección del modelo de dominio que también contiene datos específicos de vista para representar la vista. Este enfoque se llama MMVC . El controlador interactúa directamente con el modelo de dominio y presenta un modelo de aplicación a la vista. En el patrón MVVM, el modelo de aplicación y el controlador se combinan.

Michael Brown
fuente
+1: Me gusta esta respuesta lo mejor. The model is a projection of your data.La base de datos está diseñada para almacenar los datos de la manera más eficiente para acceder e indexar. El modelo debe diseñarse en torno al dominio empresarial.
Joel Etherton el
Me tomó un segundo analizar the Domain Model (what's mapping to your database). ¡Buena respuesta!
2
+1 Esta es una gran descripción de los diferentes sabores en los que MVC ha evolucionado.
Ryan Hayes
Gracias chicos. Me he sumergido profundamente en estas cosas mientras escribía mi libro. Me alegro de que tenga sentido!
Michael Brown
3
  1. No necesita una base de datos para MVC. Si su modelo habla con la base de datos, entonces genial. También podría persistir en un archivo plano, o no persistir en absoluto.

  2. El modelo es donde se almacenan los datos en la memoria de su aplicación. También querrá usar el modelo para hacer cálculos y validaciones en sus datos. Por ejemplo, tiene un modelo de FinancePayment, con propiedades como tasa de interés, plazo y principio. Puede agregar un método getMonthlyPayment () a su modelo para calcular el pago mensual. No querrás hacer eso en el controlador o la vista.

  3. La vista debe ser razonablemente tonta, ya sea que no tenga lógica en absoluto o que use solo un enlace de datos simple (vea los patrones de Vista pasiva y Controlador supervisor en el sitio de Martin Fowler ). La vista genera eventos cuando el usuario hace cosas, como hacer clic en un botón.

  4. El controlador es responsable de manejar eventos (ejecuta un código cuando el usuario hace clic en el botón Guardar), y de configurar las propiedades del modelo, y decirle al modelo que se cargue y se guarde a sí mismo (si usa persistencia). El controlador no debe hacer cálculos con los datos del modelo. Sin embargo, en el controlador, puede hacer algunos cálculos en nombre de la vista, como "if model.profit () <0 then widget.colour = 'red'"

  5. Debería poder cambiar a una versión de línea de comandos de su aplicación sin cambiar los modelos y sin perder la funcionalidad de los modelos.

a. Probablemente debería poder cambiar a una versión móvil de su aplicación (a diferencia de una versión de escritorio) solo cambiando las vistas (y no los controladores o modelos). Debería poder realizar una prueba unitaria de sus modelos y controladores sin un marco de prueba de GUI.

Neil McGuigan
fuente
¡Tocar el asunto exacto! Esto es muy claro.
2

El modelo es el código que tiene conexión a V y C en el frontend, y al almacenamiento persistente (puede ser cualquier cosa, desde archivos a bases de datos SQL / NoSQL) en el backend. No es solo el código que se carga desde db y se almacena en db (que es uno de los malentendidos del modelo), es el código que realmente hace todo el trabajo de "dominio": selecciona, filtra, altera, computa, decide sobre el datos. Incluye toda la lógica no UI de la aplicación.

herby
fuente
Los datos sin procesar que desea tener persistentes. En cualquier organización que se ajuste mejor a su modelo. El modelo es una API que hace que la lógica de su aplicación esté activa. Esa base de datos es el almacenamiento de los datos (no vivos). Si es posible para su aplicación (no sé qué tipo de aplicación es), intente dejar de pensar en ella como una "aplicación respaldada por una base de datos", pero solo una "aplicación", que utiliza una base de datos como medio para persistir los datos del módulo. Muchos problemas surgen de "iconizar" la base de datos: no es más que un almacenamiento de datos para el modelo; puedes deshacerte de él, reestructurarlo o reemplazarlo si es útil.
herby
(lo anterior solo se aplica a escenarios en los que los datos en db no se comparten con otra aplicación)
herby
Pido disculpas por la mala elección de palabras en mi comentario; lo que quise decir es que no estoy seguro de qué hay en la base de datos, con respecto a MVC . ¿La base de datos está fuera de MVC? ¿Es parte del modelo? Es parte de V o C (probablemente no, pero entiendes el punto).
Veo. Probablemente dedujo de mi respuesta que puede verlo como parte del modelo que sirve para conservar los datos de la aplicación que procesa el código del modelo. (Veo EDITAR): si esa base de datos es algo que debe sobrevivir a la aplicación, mire la base de datos como el servicio externo, con qué modelo debe comunicarse, obtener datos para el cálculo y también enviar algunos de vuelta.
herby
En el caso extremo, cuando la lógica de negocios está en la base de datos en sí, puede tener un modelo muy delgado que se transmite principalmente a la base de datos, o incluso decir que db es su modelo (pero entonces, debería tener toda la lógica).
herby
2

Tomando una visión muy simplista e idealista.

El Modelo generalmente se ve como un modelo del dominio (más o menos, el negocio), no como un modelo de los datos. Estos pueden parecer similares, pero no están completamente vinculados entre sí.

La Vista debe ser un modelo del front-end de la aplicación y el Controlador debe ser un modelo del flujo de una vista a otra.

La lógica empresarial debe estar completamente encapsulada en el Modelo, ya sea en la base de datos o en el código. Aunque es posible que se repita cierta lógica empresarial en la Vista o el Controlador, por varias razones, debería ser posible (y seguro) eliminar esos dos componentes por completo y colocar un front-end diferente en su lugar.

pdr
fuente
1

A mi entender, MVC es solo la descripción del patrón arquitectónico de su aplicación cliente. La imagen aquí en Wikipedia solo muestra esto:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Por supuesto, cuando tiene partes de su aplicación implementadas en "procedimientos almacenados", entonces ese código de base de datos también puede ser parte del modelo, o incluso del controlador (dependiendo de lo que haga el código). Pero si ese no es el caso, entonces la base de datos está claramente "fuera de MVC", tal como lo indicó.

Doc Brown
fuente
1
But then, what is in the database -- is that not also the model?

No, no es. " El modelo gestiona el comportamiento y los datos del dominio de la aplicación". A menudo, el Modelo se conecta a una base de datos, sí, pero de ninguna manera es un requisito. El modelo es una nueva capa entre su aplicación y la base de datos. El backend podría ser un conjunto de objetos Mock, XML o cualquier otra cosa que admita la persistencia de datos.

Al desacoplar las capas, se proporciona una flexibilidad mucho mayor para utilizar mejores prácticas de prueba de unidad, hacer que el código sea más manejable (EG SQL se reemplaza por Oracle), entre otros beneficios.

Lo mismo ocurre con el controlador. MVC define el controlador como un intermediario entre las dos capas. No hay una "capa empresarial" definida en MVC. Más bien, agregas el tuyo. MVC no encapsula todas las capas necesarias para construir la mayoría de las aplicaciones. Es solo una guía general para la estructura básica.

Estas separaciones son clave para permitir que funcione la inversión de control.

P.Brian.Mackey
fuente
+1 para una respuesta excelente y muy informativa; aunque sugeriría que la oración final merece aclaración. IoC no es necesariamente tan ampliamente conocido y entendido, por lo que podría agregar un poco de confusión. Una explicación realmente útil de lo que quieres decir con eso probablemente está más allá del alcance de una respuesta sensata de SE, pero me llamó la atención.
Adam Crossland
Sin embargo, si coloca su lógica empresarial en procedimientos almacenados, entonces sí, la base de datos abarca el modelo. (Personalmente, no recomendaría ese enfoque.)
Roy Tinker
1
@Roy Tinker - No, eso no importa. El modelo está conceptualmente separado. Habrá entidades que se integrarán con la base de datos en algún lugar dentro de la capa. Estas entidades deben permanecer desacopladas de otras entidades que existen dentro del modelo que tienen otras relaciones (una simulación, por ejemplo). El controlador debe realizar sus llamadas al modelo de tal manera que no tenga conocimiento de cómo y de dónde provienen los datos. Más bien, esta determinación debe hacerse con inyección de dependencia e IoC (básicamente es una interfaz que puede estar vinculada a diferentes backends, burlas o una base de datos).
P.Brian.Mackey
1

La base de datos es un detalle de implementación del modelo. El modelo debe ser un modelo de dominio completo y debe combinar datos y procesos. La separación debe ser entre preocupaciones de diferencia y no entre un proceso y los datos relacionados con ese proceso.

Ver también: http://martinfowler.com/bliki/AnemicDomainModel.html

Paris Sinclair
fuente
0

Es muy simple en realidad, "Modelo" representa la abstracción para la interfaz de datos. Es por eso que:

  • Las bases de datos se consideran parte del modelo , pero no el modelo en sí.
  • Los datos del modelo pueden provenir de bases de datos, archivos, servicios web o incluso burlarse de ellos.
  • Las clases de modelos en MVC, HMVC o marcos similares deberían almacenar consultas (ver principio "modelo gordo, controlador delgado" [ 1 ] [ 2 ] [ 3 ])

Y, si estoy en lo cierto, es por eso que cuando alguien se refiere a modelos fuera del contexto MVC, es probable que alguien se refiera al estructura de los datos (es decir, el esquema ).

dukeofgaming
fuente
0

Creo que la M contiene algo de lógica y almacena datos en DB. El controlador invoca qué módulo se ejecutará y este módulo ejecutará lógicas y almacenará datos en DB (puede tener una capa persistente) y luego este módulo devolverá el valor a V.

Mark xie
fuente
0

La M (odel) en el MVC debe capturar el modelo de la empresa / dominio en un solo lugar.

Idealmente, eso debería incluir las reglas de negocio del dominio, así como su estructura.

Lo ideal es que el C (controlador) solo se ocupe de mediar la información del modelo de negocio en la presentación (por ejemplo, la Vista) y capturar la entrada del usuario desde V (iew) para iniciar cambios en el estado del modelo.

La capa de base de datos solo trata (o más bien solo debe tratar) con la persistencia del estado del modelo en un punto particular en el tiempo.

Como tal, no es algo que pertenezca a la parte Modelo o Controlador del patrón MVC, sino que es una preocupación completamente separada que puede implementarse implícitamente persistiendo de manera transparente cualquier cambio en el modelo (en función de la fachada, proporcionando el interacciones con su Modelo para el Controlador) o como se hace más a menudo que no, llamado explícitamente por el Controlador después de que haya terminado de hacer mutaciones en el modelo.

Roland Tepp
fuente
0

El modelo en un mundo ideal solo debe contener lógica de negocios, modela algún objeto real como una casa. Sin embargo, en casi todas las circunstancias, el modelo necesita conservar sus datos en algún almacenamiento.

Las interacciones entre el modelo y los datos almacenados pueden suceder en una capa de datos separada o directamente en el modelo, que es el caso cuando se usa un ORM (Object Relational Mapper). En otras palabras, el modelo se conecta directamente a la base de datos o pasa sus datos a algún otro objeto de "acceso a datos" que se conecta a la base de datos.

Un ORM (Object Relation Mapper) asigna campos en la tabla de la base de datos a los atributos de su objeto modelo, proporcionando captadores y definidores. En este caso, no hay una capa de datos separada y el modelo es directamente responsable de conservar sus datos.

Aquí hay un ejemplo de Ruby que usa ActiveRecordun ORM popular:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Pricees un campo en la housestabla que se detecta automáticamente mediante el ActiveRecordcual agrega un captador y definidor al objeto. Cuandosave se llama, el valor del atributo de precio se conserva en la base de datos.

Desde mi punto de vista, la ventaja de tener una capa de datos es que obtienes un punto en el que puedes manipular los datos antes de que lleguen al modelo, el modelo tiene menos de qué preocuparse, tiene menos responsabilidades. Por ejemplo, es posible que necesite combinar datos de varias fuentes de datos no compatibles, esto es algo que un ORM no puede manejar fácilmente.

La principal desventaja es su otra capa de abstracción para administrar, si no la necesita, no se moleste, manténgala simple. Menos partes móviles, menos errores.

Kris
fuente
-1

Sí, tiene usted razón.

(Controlador de vista de modelo)

Una arquitectura para construir aplicaciones que separan los datos (modelo) de la interfaz de usuario (vista) y el procesamiento (controlador).

En la práctica, las vistas y controladores MVC a menudo se combinan en un solo objeto porque están estrechamente relacionados. De acuerdo con MSDN

El controlador interpreta las entradas del mouse y el teclado del usuario, informando al modelo y / o the view to change as appropriate.

Mira este diagrama:

ingrese la descripción de la imagen aquí

Por ejemplo, el código del controlador valida una solicitud de datos y hace que se devuelva en una vista. Los objetos del controlador de vista están vinculados a un solo modelo; sin embargo,a model can have many view-controller objects associated with it.

Niranjan Singh
fuente
44
In practice, MVC views and controllers are often combined into a single object because they are closely related.Si estás haciendo eso, lo estás haciendo mal ...
yannis
¿De dónde es el diagrama? ¿Y de dónde viene la definición? Por favor, no solo copie cosas de Internet sin atribuirlas correctamente.
Yannis
@ Yannis Rizos - Está citando documentación de MS. Aquí está un poco fuera de contexto, pero dicen que las aplicaciones que no son web a menudo tienen un acoplamiento de vista / controlador, pero las aplicaciones web tienen una distinción muy clara. Esta es probablemente una de las razones por las que no ve a MS presionando MVC para sus aplicaciones de Windows (MVVM en su lugar), solo aplicaciones web. msdn.microsoft.com/en-us/library/ff649643.aspx
P.Brian.Mackey
1
@ P.Brian.Mackey Sospeché que MS estaba de alguna manera detrás de esto: P
yannis
He editado su respuesta para incluir el enlace @ P.Brian.Mackey proporcionado. Está perfectamente bien citar fuentes externas, pero debe incluir enlaces a ellas. Además, MVVM puede ser muy similar a MVC, pero no es el mismo patrón. En MVC vistas y controladores nunca deben ser combinados en un solo objeto ...
Yannis