¿Cuál es el punto de usar DTO y es un concepto desactualizado? Utilizo POJO en la capa de visualización para transferir y conservar datos. ¿Se pueden considerar estos POJO como una alternativa a los DTO?
DTO es un patrón y es independiente de la implementación (POJO / POCO). DTO dice que, dado que cada llamada a cualquier interfaz remota es costosa, la respuesta a cada llamada debe traer la mayor cantidad de datos posible. Por lo tanto, si se requieren varias solicitudes para traer datos para una tarea en particular, los datos a ser traídos se pueden combinar en un DTO para que solo una solicitud pueda traer todos los datos requeridos. Catálogo de patrones de arquitectura de aplicaciones empresariales tiene más detalles.
Los DTO son un concepto fundamental, no están desactualizados.
DTO como concepto (los objetos cuyo propósito es recopilar datos para que el servidor los devuelva al cliente) ciertamente no están desactualizados.
Lo que está algo anticuado 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 a el cliente, y se asignaron para ver los modelos antes de pasarlos a la capa de visualización. En aplicaciones simples, los objetos del 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 necesario un mapeo 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 que esta noción es obsoleta en lugar de simplemente errónea es que algunos marcos / tecnologías (principalmente las más antiguas) lo requieren, ya que sus modelos de dominio y vista no son POJOS y, en cambio, están vinculados directamente al marco.
Más notablemente, los Beans de Entidad en J2EE antes del estándar EJB 3 no eran POJO y en su lugar eran objetos proxy construidos por el servidor de aplicaciones. Simplemente, no era posible enviarlos al cliente, por lo que no tenía otra opción de tener una capa DTO separada - era obligatoria.
Aunque DTO no es un patrón desactualizado, a menudo se aplica innecesariamente, lo que podría hacer que aparezca desactualizado.
El patrón más mal usado en la comunidad de 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 de manera eficiente Transporta 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 denomina DTO, pero si sus ManagedBeans y sus 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 Bean. Es probable que sus entidades JPA estén anotadas con las validaciones @NotNull y @Size. Si está usando un DTO, querrá repetir estas validaciones en su DTO para que los clientes que usan su interfaz remota no tengan que enviar un mensaje para descubrir que no han logrado la validación básica. Imagine todo ese trabajo adicional de copiar las anotaciones de Validación de Bean entre su DTO y Entidad, pero si su Vista y Entidades están operando dentro de la misma JVM, no hay necesidad de asumir este trabajo adicional: solo use las Entidades.
El enlace deIAmTheDude al Catálogo de patrones de arquitectura de aplicaciones empresariales proporciona una explicación concisa de los DTO, y aquí hay más referencias. encontrado iluminando:
¡Absolutamente no! Hace poco aprendí lecciones sobre cómo usar mejor los DTO en lugar del objeto comercial que usa (posiblemente vinculado a su asignador ORM).
Sin embargo, solo úselos cuando sean apropiados para usar y no solo por usarlos porque se mencionan en un buen libro de patrones.
Un ejemplo típico que me viene a la mente es cuando expone 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 DTO.
Un lugar en el que he encontrado que los DTO son especialmente útiles es en contener lógica para respuestas API. Con este patrón, es fácil administrar diferentes tipos de respuestas de objetos a varios formatos de manera comprobable. Al usar 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 isomórfica con varios clientes (http / mobile). Definitivamente no está desactualizado.
Lea otras preguntas en las etiquetas java design-patterns