Por que são objetos de transferência de dados (DTOs) um anti-padrão?

Question

Eu recentemente pessoas dizendo que objetos de transferência de dados (DTOs) são um anti-padrão .

Por quê? Quais são as alternativas?

Answer 1

Alguns projectos têm todos os dados duas vezes . Assim como objetos de domínio, e uma vez como objetos de transferência de dados.

Este duplicação tem um enorme custo , de modo a arquitetura necessidades para obter um benefício enorme a partir desta separação para valer a pena.

Answer 2

DTOs não são um anti-padrão. Quando você está enviando alguns dados através do fio (por exemplo, para uma página web em uma chamada Ajax), você quer ter certeza de que você economizar largura de banda enviando apenas os dados que o destino irá utilizar. Além disso, muitas vezes é conveniente para a camada de apresentação para ter os dados em um formato ligeiramente diferente do que um objeto de negócios de origem.

Eu sei que esta é uma pergunta orientada Java, mas em linguagens .NET tipos anônimos, serialização e LINQ permitir DTOs a ser construído on-the-fly, o que reduz a configuração e sobrecarga de usá-los.

Answer 3

DTO um antipattern em EJB 3.0 diz:

A natureza peso da Entidade Feijões em especificações EJB antes EJB 3.0, resultou no uso de projetar padrões como transferência de dados Objectos (DTO). DTOs tornou-se o objetos leves (que deve ter sido a entidade próprios feijão em primeiro lugar), utilizado para o envio do dados entre as camadas ... agora EJB 3.0 especificação torna o modelo de feijão Entidade mesma como Plain antigo objeto Java (POJO). Com este novo modelo POJO, você não vai é mais necessário criar um DTO para cada entidade ou por um conjunto de entidades ... Se que pretende enviar as entidades EJB 3.0 do outro lado da camada de torná-los apenas implementar java.io.Serialiazable

Answer 4

Eu não acho que DTOs são um anti-padrão per se, mas há antipatterns associados com o uso de DTOs. Bill Dudney refere-se a DTO explosão como um exemplo:

http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf

Há também uma série de abusos de DTOs mencionados aqui:

http: // anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

Eles originado por causa de três sistemas de camadas (tipicamente utilizando EJB como tecnologia) como um meio para transmitir dados entre camadas. A maioria dos sistemas Java modernos baseados em estruturas como Spring ter uma visão simplificada alternativa usando POJOs como objetos de domínio (muitas vezes anotados com JPA etc ...) em uma única camada ... O uso de DTOs aqui é desnecessário.

Answer 5

puristas OO diria que DTO é anti-padrão porque os objetos se tornam tabela representações de dados em vez de objetos reais domínio.

Answer 6

Alguns consideram DTOs um anti-padrão devido a seus possíveis abusos. Eles são usados ??frequentemente quando eles não devem ser / não precisa ser.

Este artigo descreve vagamente alguns abusos.

Answer 7

Se você está construindo um sistema distribuído, então DTOs certamente não são um anti padrão. Nem todo mundo vai desenvolver nesse sentido, mas se você tem um (por exemplo) aplicativo Open Social tudo correr JavaScript.

Ele vai postar uma carga de dados para o API. Este é, em seguida, desserializadas em algum tipo de objecto, tipicamente, um objecto DTO / Pedido. Este pode então ser validado para garantir a entrou dados estão corretos antes de ser convertido em um objeto de modelo.

Na minha opinião, ele é visto como um anti-padrão porque é mis-utilizado. Se você não está a construir um sistema distribuído, as chances são que você não precisa deles.

Answer 8

DTO se torna uma necessidade e não um anti-padrão quando você tem todos os seus objetos de domínio objetos de carga associada ansiosamente.

Se você não fizer DTOs, você terá objetos transferidos desnecessários de sua camada de negócios para sua camada de cliente / web.

Para limitar a sobrecarga para este caso, em vez transferir DTOs.

Answer 9

A intenção de um Transferência de Dados Objeto é armazenar dados de diferentes fontes e depois transferir -lo em uma base de dados (ou remoto Fachada) de uma só vez.

No entanto, o padrão DTO viola a Individual de Responsabilidade Princípio , os dados desde o DTO não apenas lojas, mas também transfere-lo a partir de ou para o banco de dados / fachada.

A necessidade de dados separado objetos a partir de objetos de negócios não é um antipattern, uma vez que é provavelmente necessário para separar a camada de banco de dados de qualquer maneira.

Em vez de DTOs que você deve usar o Aggregate e Padrões repositório, que separa a coleção de objetos ( Aggregate ) e a transferência de dados ( Repositório ).

Para transferir um grupo de objetos que você pode usar Unidade de padrão de trabalho , que mantém um conjunto de Repositórios e um contexto de transação; a fim de transferir cada objecto no agregado separadamente dentro da transação.

Answer 10

A questão não deve ser "por que", mas " quando ".

Definitivamente a sua anti-padrão, quando apenas resultar de usá-lo é custo mais elevado - tempo de execução ou manutenção. Eu trabalhei em projetos que têm centenas de DTOs idênticas às classes de entidade do banco de dados. Cada vez que você queria acrescentar um único campo que ad para adicionar id como quatro vezes - para DTO, a entidade, a conversão do DTO para classes de domínio ou entidades, a conversão inversa, ... Você esqueceu alguns dos lugares e dados GOT inconsistente.

de não anti-padrão quando você realmente precisa representação diferente de classes de domínio - mais plana, mais rico, mais estreita, ...

Pessoalmente eu começar com classe de domínio e passá-lo ao redor, com verificação adequada nos lugares certos. Posso anotar e / ou adicionar algumas classes "auxiliar" para fazer mapeamentos, a base de dados, para formatos de serialização como JSON ou XML ... Eu sempre pode dividir uma classe para dois, se eu sinto a necessidade.

É sobre o seu ponto de vista - eu prefiro olhar para um objeto de domínio como um único objeto jogando vários papéis, em vez de vários objetos criados a partir de outro. Se a única função de um objeto tem é o transporte de dados, então é DTO.

Answer 11

Eu acho que as pessoas querem dizer que poderia ser um anti-padrão se você implementar todos os objetos remotos como DTOs. Um DTO é meramente apenas um conjunto de atributos e se você tem grandes objetos você sempre transferir todos os atributos, mesmo que você não precisa ou usá-los. Neste último caso, preferem usar um padrão Proxy.