2010-10-04 39 views
42

¿Cuál es la diferencia entre un objeto MVC Model, un objeto de dominio y un DTO?¿Cuál es la diferencia entre un objeto MVC Model, un objeto de dominio y un DTO

Mi opinión es:

MVC modelo de objetos:

Modelos de los datos que se mostrarán por una vista correspondiente. Como tal, puede no corresponderse directamente con un objeto de dominio, es decir, puede incluir datos de uno o más objetos de dominio.

  1. lado del cliente
  2. Puede contener lógica de negocio, por ejemplo, validación, propiedades calculadas, etc
  3. No hay métodos relacionados con la persistencia

objeto Dominio:

objeto que modela un objeto real mundial en el dominio del problema como reserva, el cliente, orden, etc. Se utiliza para los datos persiste .

  1. lado del servidor
  2. No lógica de negocio

DTO (Object transferencia de datos):

Un objeto utilizado para transferir datos entre las capas cuando las capas están en procesos separados, por ejemplo, de un DB a una aplicación de cliente. Permite una sola transacción a través del cable en lugar de múltiples llamadas. Un DTO contiene solo datos y métodos de acceso, sin lógica. Los datos son para una transacción DB concreta, por lo que pueden no estar directamente en un objeto de dominio, es decir, pueden incluir datos de uno o más objetos de dominio.

  1. utilizar en ambos lados como pasó entre capas
  2. ninguna lógica de negocio
  3. métodos no relacionados con persistencia

Así que para las preguntas:

(1) ¿Es mi entendimiento correcto? ¿Me estoy perdiendo algunos puntos clave?

(2) ¿Hay alguna razón para no usar objetos de Dominio como el Modelo MVC, suponiendo que los objetos del Modelo no requieren una lógica comercial adicional?

(3) ¿Hay alguna razón para no utilizar DTO como Modelo MVC, suponiendo que los objetos del Modelo no requieren una lógica comercial adicional?

Gracias.

Tim

+5

buena pregunta .. +1 – nawfal

Respuesta

7

El Dominio y DTO también pueden ser sus objetos "modelo" - se puede tener una visión para hacer que los detalles del objeto de dominio "Cliente".

Un objeto de dominio puede tener lógica de negocios para aplicar las propiedades de la entidad de dominio. la validación es uno de esos casos.El objeto de dominio por sí solo no contiene métodos relacionados con la persistencia, pero puede tener metadatos (como anotaciones) para admitir la persistencia

el modelo de programación POJO hace posible usar el mismo objeto que su dominio, DTO y objetos modelo - esencialmente, no se implementarán interfaces extrañas que solo se aplicarán a una capa, pero que no se aplicarán a otras.

+1

Sí, esto es lo que estoy haciendo. De hecho, en casi todos los casos, nunca he tenido la necesidad de usar otra cosa que no sea el objeto Dominio. DTO sería para una consulta compleja con múltiples elementos de datos que abarcan objetos de dominio. –

+1

Y una clase MVC Model separada solo es realmente necesaria si hay una lógica/procesamiento de negocios significativo asociado con los datos del modelo que se mostrará? –

+1

sí, esa será una razón para tener un modelo dedicado adecuado en lugar de usar un objeto de dominio. Su objeto de dominio puede estar almacenando la fecha solo UTC y eso es suficiente para toda su lógica de negocios también. Pero en la interfaz de usuario, digamos que tendrá que mostrarlo en la zona horaria de la cuenta del usuario. Un modelo será útil para hacer estos cálculos específicos de UI. – kartheek

11

Los objetos de dominio y modelo son esencialmente los mismos, y pueden contener lógica comercial. Dependiendo de la implementación, los objetos de dominio y DTO pueden ser equivalentes si elimina la lógica de negocios del modelo en una clase de servicio.

A menudo, una variante clave del DTO es el modelo de vista, que se usa puramente para transferir datos entre el modelo de dominio y la vista, aunque a menudo un modelo de vista puede contener lógica, aunque esto debería ser puramente lógica de UI.

+0

Gracias a los dos respondientes. Me parece más claro ahora. Los objetos de dominio pueden tener lógica comercial como validación, lógica relacionada directamente con los datos. –

+2

Un objeto MVC Model separado solo es necesario para encapsular la lógica relacionada con la visualización de los datos en la vista. Si no hay ninguno, entonces es más fácil usar el objeto de dominio como el objeto Modelo de MVC. –

1
A DTO = is an object that carries data between processes. 

¡Pero la parte más interesante es que no tiene ningún comportamiento excepto para el almacenamiento y la recuperación de sus propios datos!

Siguiendo con la metodología MVC ...

Domain = subject of your entire application. 

Model = contains the (programming languages objects : EX: C# objects) to make up the universe of your application. 

Pueden tener obvioussly comportamiento y las propiedades (véase la diferencia con DTO).

A menudo una aplicación (una liviana) puede tener un modelo - caso en el que su modelo es exactamente su dominio. Otro modelo puede ser, un tipo de objeto totalmente diferente, que está procesando otro. Ambos, en este caso, son parte de su dominio y se denominan "modelos de dominio - objetos".

Esperamos que esta respuesta sea exhaustiva y lo deje todo en claro!

0

1) No, es una definición de ViewModel. MVC Model Object y Domain Object son iguales.
2) Los Modelos de dominio (Objetos) están siempre presentes, la lógica de negocios es opcional
3) Si no hay lógica comercial en Objeto de Dominio, automáticamente se convierte en DTO.

0

Cualquier definición para la mayor parte de los objetos es vario basada en el lugar de la utilización de objetos:

Model: es una definición generalpara el uso de objeto en cliente o servidor.

  1. Model View: es una objeto usando en client mayor parte del tiempo.
  2. Domain Object: es un objeto usando en server y transfering data to the database.
  3. Data Transfer Object(DTO): es un objeto que transferir datos de un objeto a otro objeto, especialmente en la obtención de datos en API Call (por ejemplo: en api método GET convocatoria para la obtención de datos no debe dar modelos de bases de datos de clientes, para este propósito, usa dto).

Aviso: the definitions are true most of the time pero en algunas situaciones no son prácticos.

Cuestiones relacionadas