¿El patrón de DTO está obsoleto o no?

Question

En una aplicación Java EE completa que está agrupada, ¿el patrón DTO sigue siendo una opción válida? La aplicación en cuestión usa EJBs Hibernate y Struts con Spring, etc. ¿Hay algún problema con la transferencia de objetos de dominio en tal escenario?

EDIT: Para aclarar mi pregunta, con los recursos de hoy en día y las mejoras en Java EE ¿hay alguna razón para no usar simplemente objetos de dominio? Si no hay, entonces ¿no está desapareciendo el patrón DTO y no debería usarse en nuevas aplicaciones?

Answer 1

No está en desuso. Depende de la arquitectura de la aplicación si el patrón DTO debe usarse o no. Por ejemplo, cuando desarrolle servicios web (utilizando JAX-WS o JAX-RS), debe enviar DTO a través de sus métodos web para que una aplicación cliente C# o Python pueda consumirlo, y su método web no debe devolver un objeto cuya clase tenga Anotaciones de Hibernate, recuerde que en otros idiomas la Entidad no se creará con esas anotaciones u otra lógica de negocios dentro.

---

EDITAR (Basado en su comentario): Eso depende de la arquitectura del software. Por ejemplo, estoy trabajando en un proyecto SOA y utilizamos DTO para la capa de servicios y la capa de presentación. Más profundo aún, incluso utilizamos DTO para manejar la comunicación de bases de datos dentro de los servicios, utilizamos solo SP para comunicarnos con DB, por lo que no puede trabajar Hibernate ni ninguna otra herramienta ORM, podríamos usar Spring DAO y ese framework también usa DTO. Puede encontrar muchos patrones de DTO en muchas aplicaciones hoy en día.

Más información que sería grande para esta pregunta:

• Difference between DTO, VO, POJO, JavaBeans? (donde básicamente, cualquier DTO es un POJO).
• Core J2EE Patterns - Transfer Object

EDIT 2: Otra fuente de información que explique la razón principal para el uso de diseño de DTO, explica por Martin Fowler

• LocalDTO

Conclusión: DTO no un son anti patrón Los DTO están destinados a ser utilizados solo cuando necesita pasar datos de un subsistema a otro y no tienen una forma predeterminada o estándar para comunicarse.

Answer 2

Un patrón es de diseño puro. No hay "desaprobación" del patrón, sino menos uso a lo largo del tiempo (o uso excesivo).
Personalmente, no veo por qué no usar DTOs.
Por ejemplo, en el proyecto de código abierto oVirt tenemos entidades que representan entidades de lógica de negocios en el dominio de la virtualización.
Estas entidades se deben anotar con anotaciones de Hibernate (de hecho, hoy en día, cuando comenzamos a trabajar en Hibernate POC) y servir como DTO, y luego tener limpias de las anotaciones objetos que se asignarán a ellas (digamos, usando dozer framework) y utilizado por el cliente
(no me gusta tener código del lado del cliente con anotaciones innecesarias), o las entidades deberían servir como los objetos del cliente (objetos de valor) pasados ​​al cliente y deberíamos tener otras clases que sirvan como el Entidades DTO

El menos en el enfoque anterior es que podría tener 2 diagramas de clases paralelos, uno para DTO y otro para objetos de valor (que usan los clientes), pero, en muchos casos en el diseño, hay un comercio apagado.
Debe comprender las ventajas y desventajas y elegir lo que es mejor para usted (en nuestro caso, dado que el lado del cliente es GWT, será más fácil para nosotros buscar la separación a dos jerarquías de clase, una que sea DTO/servidor y también se puede anotar con más anotaciones del lado del servidor, y la otra se envía al código del cliente de GWT).

Answer 3

Es un patrón muy útil en Java EE.

Uso un DTO para transferir objetos de entidad relacionados desde beans EJB a la capa UI. Los objetos de entidad se obtienen de DB en una transacción (consulte TransactionAttributeType.REQUIRED) y se almacenan en el objeto DTO. El DTO es consumido en la capa UI.