model-view-controller - data transfer object c#
¿Qué es un objeto de transferencia de datos? (6)
¿Qué es un objeto de transferencia de datos?
En MVC están las clases modelo DTO, y si no, ¿cuáles son las diferencias y necesitamos ambas?
1) Para mí, la mejor respuesta a la pregunta sobre qué es un DTO es que los DTO son objetos simples que no deben contener ninguna lógica de negocio o implementación de métodos que requieran pruebas.
2) Normalmente su modelo (usando el patrón MVC) son modelos inteligentes, y pueden contener muchos / algunos métodos que hacen algunas operaciones diferentes específicamente para ese modelo (no lógica comercial, esto debería ser en los controladores). Sin embargo, cuando transfiere datos (por ejemplo, llamando a un punto final REST (GET / POST / whatever) desde algún lugar, o consumiendo un servicio web usando soa, etc ...) no desea transmitir el objeto de gran tamaño con un código que no es necesario para el punto final, consumirá datos y ralentizará la transferencia.
Con MVC, los objetos de transferencia de datos a menudo se usan para asignar modelos de dominio a objetos más simples que la vista finalmente mostrará.
De la Wikipedia :
Objeto de transferencia de datos (DTO), anteriormente conocido como objetos de valor o VO, es un patrón de diseño utilizado para transferir datos entre subsistemas de aplicaciones de software. Los DTO se usan a menudo junto con objetos de acceso a datos para recuperar datos de una base de datos.
En general, los objetos de valor deben ser inmutables. Como objetos enteros o de cadena en Java. Podemos usarlos para transferir datos entre capas de software. Si las capas de software o servicios se ejecutan en diferentes nodos remotos, como en un entorno de microservicios o en una aplicación heredada de Java Enterprise. Debemos hacer copias casi exactas de dos clases. Este es el lugar donde conocimos DTOs.
|-----------| |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------| |--------------|
En sistemas heredados de Java Enterprise, los DTO pueden tener varias cosas de EJB.
No sé si esta es una buena práctica o no, pero personalmente uso Value Objects en mi Spring MVC / Boot Projects como este:
|------------| |------------------| |------------|
-> Form | | -> Form | | -> Entity | |
| Controller | | Service / Facade | | Repository |
<- View | | <- View | | <- Entity / Projection View | |
|------------| |------------------| |------------|
La capa de controlador no sabe cuáles son las entidades. Se comunica con los objetos de forma y vista de valor . Form Objects tiene anotaciones de validación JSR 303 (por ejemplo, @NotNull) y View Value Objects tienen anotaciones de Jackson para la serialización personalizada. (por ejemplo @JsonIgnore)
La capa de servicio se comunica con la capa de repositorio mediante objetos de entidad. Los objetos de entidad tienen anotaciones JPA / Hibernate / Spring Data en él. Cada capa se comunica solo con la capa inferior. La comunicación entre capas está prohibida debido a la dependencia circular / cíclica.
User Service ----> XX CANNOT CALL XX ----> Order Service
Algunos marcos ORM tienen la capacidad de proyección mediante el uso de interfaces o clases adicionales. Por lo tanto, los repositorios pueden devolver objetos View directamente. Allí para usted no necesita una transformación adicional.
Por ejemplo, esta es nuestra entidad de usuario:
@Entity
public final class User {
private String id;
private String firstname;
private String lastname;
private String phone;
private String fax;
private String address;
// Accessors ...
}
Pero debe devolver una lista paginada de usuarios que solo incluyen id, firstname, lastname. Luego puede crear un Objeto de valor de visualización para la proyección de ORM.
public final class UserListItemView {
private String id;
private String firstname;
private String lastname;
// Accessors ...
}
Puede obtener fácilmente el resultado paginado de la capa de repositorio. Gracias a la primavera también puede usar solo interfaces para proyecciones.
List<UserListItemView> find(Pageable pageable);
No se preocupe por otras operaciones de conversión BeanUtils.copy método BeanUtils.copy funciona bien.
La definición de DTO se puede encontrar en el sitio de Martin Fowler . Los DTO se utilizan para transferir parámetros a métodos y como tipos de devolución. Mucha gente usa esos en la interfaz de usuario, pero otros inflan objetos de dominio de ellos.
Un DTO es un objeto tonto, solo tiene propiedades y posee captadores y establecedores, pero ninguna otra lógica de importancia (aparte de tal vez una implementación de comparación () o igual a ()).
Normalmente, las clases de modelo en MVC (suponiendo que .net MVC aquí) son DTO o colecciones / agregados de DTO
Un objeto de transferencia de datos es un objeto que se utiliza para encapsular datos y enviarlos de un subsistema de una aplicación a otra.
Los DTO son comúnmente utilizados por la capa Servicios en una aplicación N-Tier para transferir datos entre ella y la capa de UI. El principal beneficio aquí es que reduce la cantidad de datos que se deben enviar a través del cable en aplicaciones distribuidas. También hacen grandes modelos en el patrón MVC.
Otro uso para los DTO puede ser encapsular parámetros para llamadas a métodos. Esto puede ser útil si un método toma más de 4 o 5 parámetros.
Al usar el patrón DTO, también haría uso de ensambladores DTO. Los ensambladores se utilizan para crear DTO desde objetos de dominio, y viceversa.
La conversión de objeto de dominio a DTO y viceversa puede ser un proceso costoso. Si no está creando una aplicación distribuida, probablemente no verá grandes beneficios del patrón, como Martin Fowler explica aquí