¿Dónde está la M en MVC?

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

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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:

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.