¿Cuál es el punto de usar DTO (Data Transfer Objects)?

¿Cuál es el punto de usar DTO y es un concepto anticuado? Utilizo POJO s en la capa de vista para transferir y conservar datos. ¿Se pueden considerar estos POJO como una alternativa a los DTO?

DTO es un patrón y su implementación (POJO / POCO) es independiente. DTO dice que, dado que cada llamada a cualquier interfaz remota es costosa, la respuesta a cada llamada debería aportar la mayor cantidad de datos posible. Por lo tanto, si se requieren múltiples solicitudes para traer datos para una tarea en particular, los datos que se traerán se pueden combinar en un DTO para que solo una solicitud pueda traer todos los datos requeridos. El Catálogo de patrones de arquitectura de aplicaciones empresariales tiene más detalles.

Los DTO son un concepto fundamental, no anticuado.

DTO como concepto (objetos cuyo propósito es recopilar datos para que el servidor los devuelva al cliente) ciertamente no está desactualizado.

Lo que está algo desactualizado es la noción de tener DTO que no contienen ninguna lógica, se usan solo para transmitir datos y se "asignan" desde objetos de dominio antes de la transmisión al cliente, y se asignan para ver modelos antes de pasarlos a la capa de visualización. En aplicaciones simples, los objetos de dominio a menudo se pueden reutilizar directamente como DTO y pasar directamente a la capa de visualización, de modo que solo hay un modelo de datos unificado. Para aplicaciones más complejas, no desea exponer todo el modelo de dominio al cliente, por lo que es necesaria una asignación de modelos de dominio a DTO. Tener un modelo de vista separado que duplique los datos de los DTO casi nunca tiene sentido.

Sin embargo, la razón por la cual esta noción está desactualizada en lugar de simplemente errónea es que algunos marcos / tecnologías (principalmente más antiguos) lo requieren, ya que sus modelos de dominio y vista no son POJOS y, en cambio, están vinculados directamente al marco.

En particular, los Beans de entidad en J2EE antes del estándar EJB 3 no eran POJO y, en cambio, eran objetos proxy construidos por el servidor de la aplicación; simplemente no era posible enviarlos al cliente, por lo que no tenía opción de tener una capa DTO separada - Era obligatorio

Aunque DTO no es un patrón desactualizado, a menudo se aplica innecesariamente, lo que puede hacer que parezca desactualizado.

El patrón más mal utilizado en la comunidad Java Enterprise es el DTO. DTO se definió claramente como una solución para un problema de distribución. DTO estaba destinado a ser un contenedor de datos de grano grueso que transporta eficientemente los datos entre procesos (niveles). ~ Adam Bien

Por ejemplo, supongamos que tiene un JSF ManagedBean. Una pregunta común es si el bean debe contener una referencia a una Entidad JPA directamente, o si debe mantener una referencia a algún objeto intermediario que luego se convierta en una Entidad. He escuchado que este objeto intermediario se conoce como DTO, pero si sus ManagedBeans y Entidades están operando dentro de la misma JVM, entonces hay poco beneficio al usar el patrón DTO.

Considere las anotaciones de validación de frijoles. Es probable que sus entidades JPA estén anotadas con las validaciones @NotNull y @Size. Si está utilizando un DTO, querrá repetir estas validaciones en su DTO para que los clientes que usan su interfaz remota no necesiten enviar un mensaje para descubrir que han fallado la validación básica. Imagine todo ese trabajo adicional de copiar anotaciones de Validación de Bean entre su DTO y la Entidad, pero si su Vista y Entidades están operando dentro de la misma JVM, no hay necesidad de realizar este trabajo adicional: solo use las Entidades.

El enlace de IAmTheDude al Catálogo de patrones de arquitectura de aplicaciones empresariales proporciona una explicación concisa de los DTO, y aquí hay más referencias que encontré esclarecedoras:

• CÓMO TRATAR CON J2EE Y PATRONES DE DISEÑO
• Cómo usar DTO en JSF + Spring + Hibernate
• Pros y contras de los objetos de transferencia de datos

¡Absolutamente no! Hace poco aprendí lecciones sobre el mejor uso de DTO en lugar del objeto comercial que usa (posiblemente vinculado a su mapeador ORM).

Sin embargo, solo úselos cuando sea apropiado y no solo por usarlos porque se mencionan en algún buen libro de patrones.
Un ejemplo típico que me viene a la mente es cuando expones algún tipo de interfaz a terceros. En tal escenario, le gustaría mantener los objetos intercambiados bastante estables, lo que generalmente puede lograr muy bien con los DTO.

Un lugar en el que he encontrado que los DTO son especialmente útiles es contener lógica para las respuestas API. Con este patrón, es fácil administrar diferentes tipos de respuestas de objetos a varios formatos de manera comprobable. Usando este patrón en mi rol actual, pudimos comenzar a probar los formatos de respuesta para nuestras API, lo cual ha sido valioso ya que nuestra pila se está volviendo más isomorfa con varios clientes (http / mobile). Definitivamente no está desactualizado.