Objetos de transferencia de datos, objetos de dominio y repositorios

Question

Estoy intentando descubrir cómo funcionan todos estos elementos juntos. Sé que un DTO es básicamente un contenedor de datos para que los Objetos del Dominio pasen de un lado a otro a formularios y demás. ¿El objeto de Dominio contiene un DTO o el DTO y el objeto de dominio pasa a tener todas las mismas propiedades que se mapearán manualmente?

Si expongo mi tipo de DTO en un servicio, ¿cómo uso los getters y setters sin crear un viaje de ida y vuelta para cada operación get/set en el cliente? Sé que puedes tener un constructor largo, pero eso puede ponerse feo si tienes más de 7 propiedades.

Al implementar el patrón Repositorio, ¿paso el DTO o el objeto de dominio?

Answer 1

• Los DTO y los objetos de Dominio deben estar separados.
• Debe haber un asignador que asigne un DTO a un objeto de dominio y un objeto de dominio a un DTO. Este correlacionador debe ser una implementación de una interfaz, con el correlacionador por defecto usando la reflexión para mapear los objetos entre sí.
• El repositorio debe ser un servicio que devuelve los objetos del dominio, que a su vez deberían ser servicios.
• Si el DTO es una clase expuesta por un servicio web, el WSDL que se crea define la propiedad como un elemento, y el proxy que se crea en el otro lado simplemente crea una propiedad getter/setter que se ejecuta el cliente mismo, por lo que los getters y setters no causan un viaje de ida y vuelta.
• Incluso si solo crea una variable pública en su DTO, el proxy se implementará como getter y setter.

Answer 2

Creo que es mejor tener el DTO que contiene una referencia al objeto de dominio para que los consumidores de DTO puedan comenzar a utilizar el objeto de dominio. Dicho esto, si los consumidores de DTO no deben mutar el objeto de Dominio, es posible que necesite que el DTO contenga los valores encapsulados en el objeto de Dominio. Esto puede ser difícil ya que puede necesitar hacer una copia profunda del objeto de Dominio.

No estoy seguro de por qué es un problema que exponer un tipo de DTO como un servicio causaría el uso de sus getters/setters para hacer un viaje de ida y vuelta. Si el servicio es un servicio remoto, el DTO devuelto se serializa de todos modos y sus getters/setters obtendrán la copia de los valores. Si el servicio no es remoto, no parece ser una gran pena hacer un "viaje redondo" ya que el cliente y el servicio se encuentran en el mismo espacio de proceso.