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

120

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

    
por Vinoth Kumar C M 26.10.2012 / 07:27
fonte

5 respostas

101

DTO é um padrão e é implementação (POJO / POCO) independente. DTO diz, uma vez que 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 de Arquitetura de Aplicativos Corporativos tem mais detalhes.

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

    
por 26.10.2012 / 12:11
fonte
54

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

O que é 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 para o cliente, e lá mapeado para ver os 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 passados diretamente para a camada de exibição, de modo que haja apenas um modelo de dados unificado. Para aplicativos mais complexos, você não deseja expor todo o modelo de domínio ao cliente, portanto, é necessário um mapeamento dos modelos de domínio para os 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 as mais antigas) exigem isso, pois seus modelos de domínio e visão não são POJOS e, em vez disso, vinculados diretamente à estrutura.

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

    
por 26.10.2012 / 12:25
fonte
16

Embora o DTO não seja um padrão desatualizado, ele é aplicado sem necessidade, o que pode parecer desatualizado.

The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). ~ Adam Bien

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

Considere as anotações de validação do bean. Suas Entidades JPA provavelmente são anotadas com as validações @NotNull e @Size. Se você estiver usando um DTO, convém repetir essas validações em seu 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 Bean Validation entre seu DTO e Entity, mas se sua View e Entities estiverem operando dentro da mesma JVM, não há necessidade de fazer este trabalho extra: apenas use as Entities.

O link do IAmTheDude para Catálogo de Padrões de Arquitetura de Aplicativos Corporativos fornece uma explicação concisa de DTOs, e aqui estão mais referências I encontrado iluminante:

por 16.12.2014 / 21:50
fonte
8

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

No entanto, basta usá-los quando eles forem apropriados para usar e não apenas para usá-los, porque eles são mencionados em um bom livro de padrões.
Um exemplo típico que me vem à mente é 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 pode ser bem feito com DTOs.

    
por 26.10.2012 / 13:30
fonte
0

Um lugar que eu acho que os DTOs são especialmente úteis é em conter lógica para respostas de 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 é valioso, já que nossa pilha está se tornando mais isomórfica com vários clientes (http / mobile). Definitivamente não está desatualizado.

    
por 29.05.2018 / 17:36
fonte