model view controller - example - Diferenciar entre dominio, modelo y entidad con respecto a MVC
model view controller php (5)
Ambos dominios y modelos son clases. La forma en que se usa la clase distingue si debe clasificarse y colocarse en un dominio o carpeta de modelo. Si la clase se utilizará SOLAMENTE en la vista, colóquela en la carpeta del modelo. Si la clase está asignada a un objeto de base de datos, póngalo en la carpeta del dominio.
¿Alguien puede explicar estos 3 conceptos y las diferencias entre ellos con respecto a un marco MVC junto con un ejemplo? Para mí, estos parecen casi equivalentes, y parece que se usan indistintamente en algunos artículos y no en otros.
Los términos con los que está confundido son: " objetos de dominio ", "entidades de dominio" y "objetos modelo". Aunque normalmente se usan indistintamente, las entidades de dominio y el objeto modelo también pueden ser instancias de patrón de registro activo (básicamente: objetos de dominio con lógica de almacenamiento agregada).
En el objeto de dominio ordinario no hay lógica de almacenamiento. Es manejado por los mapeadores de datos .
El término "objetos modelo" proviene de los libros de Fowler (lea PoEAA para más detalles) y, en mi humilde opinión, forma parte de las confusiones MVC, porque todo el modelo es una capa de aplicación (MVC consiste en ella y capa de presentación), que contiene "objetos modelo", que generalmente son tratados por los services (en esa imagen, la capa modelo son los tres círculos concéntricos).
Prefiero usar el término "objeto de dominio" en su lugar.
El término "entidad de dominio" (u "objeto de entidad") se usa generalmente cuando el autor implica que el objeto es una representación directa de una estructura de almacenamiento (más a menudo, una tabla de base de datos). Estas también son casi siempre implementaciones de registro activo.
PD: en algunos artículos también verías el término "modelos" (plural). Por lo general, no está directamente relacionado con el patrón de diseño de MVC, ya que habla de la arquitectura tipo Rails, donde los "modelos" son solo registros activos, que se exponen directamente al controlador / lo crean.
.. no estoy seguro de si esto te confundió más
Los términos son un poco vagos, estoy de acuerdo. Utilizaría el dominio para referirme al área comercial con la que está tratando. Como banca o seguro o lo que no. Entonces tienes modelos de dominio. Estas son las cosas que maneja en ese dominio comercial, como para el dominio de la banca, tiene cuentas, clientes, transferencias, etc. Usaría la entidad de término para hacer referencia a la clase / POJO o la versión persistente / concreta de un modelo.
Lo que probablemente te confunde aquí es que en el término MVC , el modelo es algo concreto, pero hace referencia al modelo de datos utilizado para representar alguna presentación en una GUI web, así que no te mezcles con la explicación anterior.
Para el registro. En términos prácticos, el dominio y el modelo son los mismos, mientras que la entidad también es un dominio / objeto que se usaría para almacenar en la base de datos.
Algunas personas intentan volver a explicar estos temas, pero ninguno de ellos es canon.
La diferencia es que, en el mundo de Java, Dominio es más utilizado, mientras que en el mundo de C #, se usa el Modelo (y MS alienta su uso), pero es una convención y se puede usar ambos.
En el mismo concepto, Value Object (VO) es utilizado por la gente de Java, mientras que DTO para las personas de C # incluso cuando ambas son prácticamente iguales. También POJO (Java) vs POCO (C #), Paquetes (Java) vs NameSpace (C #), Setter y Getter (Java) vs Encapsulation (C #)
Se podría decir que un dominio son las clases para las tablas de la base de datos, los objetos del servicio externo, etc. Por lo tanto, si desarrolla un proyecto y crea un dominio de directorio, debe incluir los objetos de la base de datos. Una clase como esa es una Entidad y puede ser una clase Cliente con sus propiedades. ¿Por qué es eso una Entidad y no un POCO? Eso es por su uso. El contenido de la Entidad se puede leer / escribir en la base de datos. Debido a que lo piensas como una entidad, sabes dónde puedes usarlo. Por conocimiento sabes que es una Entidad, no lo pones en su nombre. Ahora para el Modelo. Si está utilizando este Cliente, puede haber propiedades que no desea usar. Un cliente puede ser una entidad realmente simple. Pero digamos que tiene uno complejo. Uno que lees de un servicio web con tantas propiedades que no usarás. Luego puede leer esta Entidad (= se puede hacer perfectamente con la serialización) y usar esta Entidad para crear un Modelo de la misma. Si esa entidad se utiliza para copiar datos al modelo, también hablamos de un objeto de transformación de datos (DTO), a veces se escribe esto como CustomerDTO. Para copiar los datos de la Entidad a un Modelo puede usar las herramientas de Mapeo. El nombre de la entidad cambia a CustomerModel. Luego usa el modelo de extensión porque de lo contrario no sabrá qué es qué. En este modelo de cliente puede haber muchas otras propiedades para. Algunas de estas propiedades pueden ser propiedades de proceso (no deben venir de la entidad Cliente). El contenido de estas propiedades proviene de otros servicios. Uno simple que se puede crear desde el Cliente es Nombre completo, está formado por varias propiedades del Cliente. Entonces llenar un Modelo de Cliente puede ser complejo. Podemos poner el código para llenar CustomerModel en una fábrica llamada y llamar a este CustomerFactory.