DTO: mejores prácticas

Question

Estoy considerando utilizar DTO en lugar de pasar alrededor de los objetos de mi dominio. He leído varios mensajes aquí y en otros lugares, y entiendo que hay varios enfoques para hacer esto.

Si solo tengo unas 10 clases de dominio en total, y considerando que quiero usar DTO en lugar de objetos de dominio para el consumo en mis Vistas (interfaces WPF), ¿cuál es el enfoque recomendado? Creo que el uso de herramientas como Automapper, etc. puede ser una exageración para mi situación. Así que estoy pensando en escribir mi clase de asignador personalizada que tendrá métodos para convertir un tipo de dominio a un tipo de DTO.

¿Cuál es la mejor manera de hacer esto? ¿Hay alguna muestra para comenzar a hacer esto?

Segunda pregunta: Al escribir los métodos que crearán DTO, ¿cómo trato con la configuración de todos los datos, especialmente cuando el tipo de dominio tiene referencias a otros objetos de dominio? ¿Escribo propiedades equivalentes en el DTO para mapear a esos tipos de referencia en la clase de dominio? Por favor, pregunte si no he puesto mi segunda pregunta en palabras adecuadas. Pero creo que entiendes lo que estoy tratando de preguntar.

Thrid pregunta, ¿debo escribir DTO múltiples, cada uno con datos parciales para un modelo de dominio dado, de modo que cada uno de ellos se pueda utilizar para satisfacer un requisito de una Vista específica, o DTO debe tener todos los datos que están ahí en la clase de modelo correspondiente.

Answer 1

Supongo que los objetos de su modelo de dominio tienen una ID de clave principal que puede corresponder a los ID de la base de datos o almacén de donde provienen.

Si lo anterior es cierto, entonces su DTO superará el tipo de referencia a otras DTO como los objetos de su dominio, en forma de una ID de clave externa. Entonces, una relación OrderLine.OrderHeader en el objeto de dominio será OrderLine.OrderHeaderId cin the DTO.

Espero que ayude.

¿Puedo preguntar por qué eligió utilizar DTO en lugar de sus objetos de dominio enriquecido en la vista?

Answer 2

Estoy usando DTO en un proyecto. Tiendo a hacer los DTO solo para mostrar los datos que necesito para una vista específica. Recojo todos los datos que se muestran en la vista en mi clase de acceso a datos. Por ejemplo, es posible que tenga un objeto Orden que hace referencia a un objeto Cliente:

public class Client{ 
    public int Id{get;set;} 
    public string Name{get;set;} 
} 

public class Order{ 
    public int OrderID{get;set;} 
    public Client client{get;set;} 
    public double Total{get;set;} 
    public IEnumerable<OrderLine> lines {get;set;} 
} 

Luego, en mi OrderListDTO que puede tener algo como:

public class OrderListDTO{ 
    public int OrderId{get;set;} 
    public string ClientName{get;set;} 
    ... 
} 

¿Cuáles son los campos que quiero mostrar mi punto de vista . Busco todos estos campos en mi código de acceso a la Base de datos para no tener que preocuparme por las asociaciones de entidades en mi código de vista o controlador.

Answer 3

He estado leyendo algunos comentarios aquí con respecto a los DTO y me parece que muchas personas los equiparan a lo que yo consideraría un ViewModel. Una DTO es solo eso, Objeto de transferencia de datos: es lo que se transmite por el cable. Así que tengo un sitio web y servicios, solo los servicios tendrán acceso a objetos reales de dominio/entidad y devolverán los DTO. Pueden mapear 1: 1, pero consideran que los DTO pueden estar llenos de otra llamada de servicio, una consulta de base de datos, leyendo una configuración - lo que sea.

Después de eso, el sitio web puede tomar esos DTO y agregarlos a un ViewModel o convertirlos en uno. Ese ViewModel puede contener muchos tipos diferentes de DTO.Un ejemplo simple sería un administrador de tareas: ViewModel contiene tanto el objeto de tarea que está editando como un grupo de objetos Dto.User a los que se puede asignar la tarea.

Tenga en cuenta que los servicios que devuelven DTO pueden ser utilizados tanto por un sitio web, y tal vez una tableta o aplicación de teléfono. Estas aplicaciones tendrían diferentes vistas para aprovechar sus pantallas, por lo que los ViewModels serían diferentes, pero los DTO seguirían siendo los mismos.

En cualquier caso, me encantan este tipo de discusiones, por lo que cualquier persona hágamelo saber por favor.

Matt

Answer 4

Vengo a proyectar con spring-jdbc y no se utilizan DAO capa. Algunas veces las entidades existentes no cubren todos los datos posibles de DB. Entonces empiezo a usar DTO.

Mediante la aplicación de la regla de programación '70 estructura puse todas las OTD en paquete separado:

package com.evil.dao;  // DAO interfaces for IOC. 
package com.evil.dao.impl; // DAO implementation classes. 
package com.evil.dao.dto; // DTOs 

Ahora repensar y decide poner toda DTO como las clases internas en las interfaces DAO para conjuntos de resultados que no tienen reutilización. Así DAO mirada como el interfaz:

interface StatisticDao { 
    class StatisticDto { 
     int count; 
     double amount; 
     String type; 

     public static void extract(ResultSet rs, StatisticDto dto) { ... } 
    } 

    List<StatisticDto> getStatistic(Criteria criteria); 
} 


class StatisticDaoImpl implements StatisticDao { 
    List<StatisticDto> getStatistic(Criteria criteria) { 
     ... 
     RowCallbackHandler callback = new RowCallbackHandler() { 
      @Override 
      public void processRow(ResultSet rs) throws SQLException { 
       StatisticDao.StatisticDto.extract(rs, dto); 
       // make action on dto 
      } 
     } 
     namedTemplate.query(query, queryParams, callback); 
    } 
} 

creo que la celebración de los datos relacionados entre sí (DTO personalizada con interfaz DAO) hacer que el código mejor para PageUp/PageDown.

Answer 5

mejor manera de desarrollar dtos

La manera de empezar dtos en desarrollo es entender que su único propósito es transferir subconjunto de datos de sus entidades de negocios a los diferentes clientes (que podría ser la interfaz de usuario, o un servicio externo) Dado este entendimiento, podría crear paquetes separados para cada cliente ... y escribir sus clases de DTO. Para el mapeo, puede escribir sus propias interfaces de definición de mapeo para pasarlas a una fábrica creando objetos DTO basados ​​en los datos de la entidad para la cual se está creando el DTO. También podría definir anotaciones para colocar en los campos de su entidad, pero personalmente, dado el número de anotaciones utilizadas, preferiría la forma de interfaz. Lo principal a tener en cuenta acerca de los DTO es que también son clases y los datos entre los DTO deben reutilizarse; en otras palabras, si bien puede parecer tentador crear DTO para cada caso de uso, intente reutilizar los DTO existentes para minimizar esto.

Introducción

En cuanto Comenzando como se ha indicado anteriormente con el único propósito de la DTO es dar al cliente los datos que necesita .... por lo que teniendo en cuenta que sólo podría configurar datos en el dto el uso de fijadores ... o definir una fábrica que crea un DTO de una entidad basada en una interfaz .....

en cuanto a su tercera pregunta, hacer lo que se requiere por su cliente :)