Qual é o sentido de usar o DTO (Data Transfer Objects)?

Qual é o sentido de usar o DTO e é um conceito desatualizado? Eu uso POJOs na camada de exibição para transferir e manter dados. Esses POJOs podem ser considerados uma alternativa aos DTOs?

O DTO é um padrão e é independente da implementação (POJO / POCO). O DTO diz que, como cada chamada para qualquer interface remota é cara, a resposta a cada chamada deve trazer o máximo de dados possível. Portanto, se várias solicitações forem necessárias para trazer dados para uma tarefa específica, os dados a serem trazidos poderão ser combinados em um DTO para que apenas uma solicitação possa trazer todos os dados necessários. O catálogo de padrões da arquitetura de aplicativos corporativos tem mais detalhes.

DTOs são um conceito fundamental, não desatualizado.

DTO como um conceito (objetos cujo objetivo é coletar dados a serem retornados ao cliente pelo servidor) certamente não está desatualizado.

O que está um pouco desatualizado é a noção de ter DTOs que não contêm lógica alguma, são usados apenas para transmitir dados e "mapeados" de objetos de domínio antes da transmissão ao cliente e mapeados para exibir modelos antes de passá-los para a camada de exibição. Em aplicativos simples, os objetos de domínio geralmente podem ser reutilizados diretamente como DTOs e transmitidos diretamente para a camada de exibição, para que haja apenas um modelo de dados unificado. Para aplicativos mais complexos, você não deseja expor o modelo de domínio inteiro ao cliente, portanto, é necessário um mapeamento de modelos de domínio para DTOs. Ter um modelo de visualização separado que duplique os dados dos DTOs quase nunca faz sentido.

No entanto, a razão pela qual essa noção está desatualizada, e não simplesmente errada, é que algumas estruturas / tecnologias (principalmente mais antigas) exigem, pois seus modelos de domínio e exibição não são POJOS e, em vez disso, estão diretamente ligados à estrutura.

Mais notavelmente, os Entity Beans no J2EE anteriores ao padrão EJB 3 não eram POJOs e, em vez disso, eram objetos de proxy construídos pelo servidor de aplicativos - simplesmente não era possível enviá-los ao cliente, portanto, você não tinha escolha sobre ter uma camada DTO separada - era obrigatório.

Embora o DTO não seja um padrão desatualizado, ele é frequentemente aplicado desnecessariamente, o que pode fazer com que pareça desatualizado.

O padrão mais mal utilizado na comunidade Java Enterprise é o DTO. O DTO foi claramente definido como uma solução para um problema de distribuição. O DTO era para ser um contêiner de dados de granulação grossa que transporta dados de forma eficiente entre processos (camadas). ~ Adam Bien

Por exemplo, digamos que você tenha um JSF ManagedBean. Uma pergunta comum é se o bean deve conter uma referência a uma Entidade JPA diretamente ou deve manter uma referência a algum objeto intermediário que é posteriormente convertido em uma Entidade. Eu ouvi esse objeto intermediário chamado DTO, mas se seus ManagedBeans e Entidades estiverem operando na mesma JVM, haverá pouco benefício em usar o padrão DTO.

Considere anotações de Validação de Bean. Suas entidades JPA provavelmente estão anotadas nas validações @NotNull e @Size. Se você estiver usando um DTO, convém repetir essas validações no DTO para que os clientes que usam sua interface remota não precisem enviar uma mensagem para descobrir que falharam na validação básica. Imagine todo esse trabalho extra de copiar anotações de Validação de Bean entre seu DTO e Entidade, mas se seu View e Entidades estiverem operando na mesma JVM, não será necessário executar esse trabalho extra: basta usar as Entidades.

O link do IAmTheDude para o Catálogo de padrões de arquitetura de aplicativos corporativos fornece uma explicação concisa dos DTOs, e aqui estão mais referências que achei esclarecedoras:

• COMO LIDAR COM J2EE E PROJETAR PADRÕES
• Como usar o DTO no JSF + Spring + Hibernate
• Prós e contras dos objetos de transferência de dados

Absolutamente não! Recentemente, aprendi lições sobre como usar melhor os DTOs em vez do objeto de negócios que você usa (possivelmente vinculado ao seu mapeador ORM).

No entanto, use-os quando for apropriado e não apenas para usá-los, porque eles são mencionados em algum bom livro de padrões.
Um exemplo típico que me vem à cabeça é quando você expõe algum tipo de interface a terceiros. Nesse cenário, você gostaria de manter os objetos trocados bastante estáveis, o que geralmente é possível obter com os DTOs.

Um lugar em que achei os DTOs especialmente úteis é a lógica para as respostas da API. Com esse padrão, é fácil gerenciar diferentes tipos de respostas de objetos para vários formatos de maneira testável. Usando esse padrão na minha função atual, pudemos começar a testar os formatos de resposta para nossas APIs, o que tem sido valioso, pois nossa pilha está se tornando mais isomórfica com vários clientes (http / mobile). Definitivamente não está desatualizado.