DTO: Por que usar uma coisa dessas?

This message was edited 1 time. Last update was at 12/08/2010 15:19:13

Me deparei com um projeto onde estão usando DTO na camada de serviço. Algo como:

List<UserDTO> searchUsers( ... );

Na minha cabeça isso é o lixo do lixo.

Por que estavam fazendo isso?

Para definir o formato da resposta do WebService que é em JSON. Ex: o User pode ter um atributo firstName mais a resposta do protocolo pode esperar name.

Por que estavam usando um conversor de object para Json (JacksonView do Spring) que por reflection acessava todas as propriedades do objeto, carregando toda a hierarquia e até causando loop infinito em dependências cíclicas ManyToMany. (Obrigado Hibernate!)

O que eu falei para os malucos:

Camada de serviços só pode trabalhar com modelo, entidades reais, nunca DTO.

Quando precisar formatar alguma resposta, evitar lazy loading, trocar nome das propriedades, etc. Só há duas opções: 1) template engine (Velocity ou FreeMarker) ou 2) DTO genérico = Map

Isso é para um webservice que retorna respostas em JSON.

Então ficou a pergunta. Quando se justifica usar um DTO. Quem inventou isso?

JWizard Membro desde: 22/01/2007 22:00:53 Mensagens: 2724 Offline

Eu estou estudando EJB pelo EJB3 In Action e nele ele fala que o DTO foi "criado" para realizar a transmissão de objetos entre contextos diferentes. Pois ele não é o objeto em si, apenas uma representação dele. Ex.: Pessoa e PessoaDTO (conteria apenas strings por exemplo)

Eu trabalhei em um sistema que usava DTO como meio de transporte de informação da View para o Controller. Ao invés de se passar um monte de String picada para o controller trabalhar, passava o DTO que já era o objeto que a View montou.

Mais info, aqui ó.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
http://en.wikipedia.org/wiki/Data_transfer_object
http://www.theserverside.com/discussions/thread.tss?thread_id=32389

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Exemplo tosco e mal pensado mas que ajuda a explicar:

Voce tem um servico remoto que calcula imposto de cada produto de um carrinho de compras.

Se por acaso seu carrinho tem milhares de itens, serao geradas milhares de chamadas remotas, gastando muito com I/O.

Alguem poderia fazer algo assim:

Pra economizar chamadas remotas.

Eu partilho da sua aversão a DTO. Acho que ele é um ótimo pattern... pro ano 2000. Hoje em dia, não tem a menor necessidade, seja em qualquer contexto, web services ou não, porque:

1) Se for um ambiente Java puro, o EJB3 pode muito bem trafegar sem carregar as dependências desnecessárias.

2) Se for um ambiente composto de web services, só anotar os atributos que não desejamos trafegar. Isso inclui, claro, referências a listas.

Acho que o único caso em que se aplica, se for, é o caso em que eu desejo apresentar diferentes visões dos objetos para diferentes clientes. Só que, isso já muda o Design Pattern, já que DTO é feito para falar de transferência de dados e não de máscara de dados. Não sei qual seria o nome do pattern, então, só sei que DTO é que não é.

[]´s

Rubem Azenha wrote:http://martinfowler.com/eaaCatalog/dataTransferObject.html

Exemplo tosco e mal pensado mas que ajuda a explicar:

Voce tem um servico remoto que calcula imposto de cada produto de um carrinho de compras.

public Imposto calcularImposto(Produto produto, int quantidade)

Se por acaso seu carrinho tem milhares de itens, serao geradas milhares de chamadas remotas, gastando muito com I/O.

Alguem poderia fazer algo assim:

public Imposto calcularImposto(CarrinhoDeCompras carrinhoDeCompras)

Pra economizar chamadas remotas.

OK, mas com a velocidade de transferência de que dispomos hoje, talvez seja mais interessante (às vezes) trafegar várias vezes pacotes pequenos, dando a chance de outros consumidores efetuarem também pequenos processamentos, do que cada um enviar um pacote muito grande, não? Assim, se der algum problema em alguma das chamadas (a rede não é perfeita), o processamento todo não é perdido. O que você acha?

[]´s

asaudate wrote:
OK, mas com a velocidade de transferência de que dispomos hoje, talvez seja mais interessante (às vezes) trafegar várias vezes pacotes pequenos, dando a chance de outros consumidores efetuarem também pequenos processamentos, do que cada um enviar um pacote muito grande, não? Assim, se der algum problema em alguma das chamadas (a rede não é perfeita), o processamento todo não é perdido. O que você acha?

[]´s

Eu acho que DTO é uma pattern que deve ser aplicada apenas se e quando depois de medir o desempenho da aplicacao, utilizando um profiler ou outra ferramenta adequada, for identificado que o I/O gerado pelas multiplas chamadas é o gargalo. Realmente nao deve ser a abordagem default para servicos remotos.

jakefrog wrote:
Eu estou estudando EJB pelo EJB3 In Action e nele ele fala que o DTO foi "criado" para realizar a transmissão de objetos entre contextos diferentes. Pois ele não é o objeto em si, apenas uma representação dele. Ex.: Pessoa e PessoaDTO (conteria apenas strings por exemplo)

Sim, mas vc pode usar um Map que é um DTO genérico para qualquer objeto. Ficar criando um DTO para cada comunicação que vc precisa fazer é overkill.

Eu trabalhei em um sistema que usava DTO como meio de transporte de informação da View para o Controller. Ao invés de se passar um monte de String picada para o controller trabalhar, passava o DTO que já era o objeto que a View montou.

Como eu falei: acredito que o certo nesse caso é passar os próprios objetos do negócio para a view e ela se encarrega de apresentá-los da maneira que ela quiser via templates, JSP, tags, etc. No meu caso a minha view usava reflection para converter o objeto para JSON, o que poderia ser um problema. Então teria que ter uma camada intermediária para preparar um Maps (DTO genérico) para a view. Mas isso nunca deveria ter sido feito na camada de serviços.

Rubem Azenha wrote:http://martinfowler.com/eaaCatalog/dataTransferObject.html

Exemplo tosco e mal pensado mas que ajuda a explicar:

Voce tem um servico remoto que calcula imposto de cada produto de um carrinho de compras.

public Imposto calcularImposto(Produto produto, int quantidade)

Se por acaso seu carrinho tem milhares de itens, serao geradas milhares de chamadas remotas, gastando muito com I/O.

Alguem poderia fazer algo assim:

public Imposto calcularImposto(CarrinhoDeCompras carrinhoDeCompras)

Pra economizar chamadas remotas.

Não entendi.

Vc vai passar o objeto de negócio Produto ou vai passar um ProdutoDTO. Mesma coisa para o CarrinhoDeCompras.

A comunicação entre sistemas deve ser feita via JSON ou XML. O que se faz é usar DTO como TEMPLATE para FORMATAR essa resposta. Meu ponto é que o melhor é usar template engine ou um DTO genérico (MAP).

This message was edited 1 time. Last update was at 12/08/2010 16:03:39

Acho que o único caso em que se aplica, se for, é o caso em que eu desejo apresentar diferentes visões dos objetos para diferentes clientes. Só que, isso já muda o Design Pattern, já que DTO é feito para falar de transferência de dados e não de máscara de dados. Não sei qual seria o nome do pattern, então, só sei que DTO é que não é.

O que vejo é que as pessoas estão usando DTO como TEMPLATE ENGINE. No teu caso, cada cliente seria direcionado para um template diferente. Se vc não quiser usar templates, vc teria um IF onde um Map seria preparado de maneira diferente para cada cliente. Depois esse MAP seria convertido para JSON ou XML. No caso aqui estou falando de WebService. Se fosse uma aplicação web vc teria um IF dentro do seu JSP ou dois JSPs diferentes.

O que me deu vontade de fazer foi o seguinte.

Para web services

Ao invés de dar um forward para um JSP ou TEMPLATE ENGINE que fai gerar a resposta a partir dos OBJETOS DE NEGOCIO.

Vc dá um forward para um Objeto Java que vai preparar o MAP. Depois esse MAP é convertido para JSON e pronto.

Seria uma maneira de organizar as versões por examplo, para vc não ter um milhão de IFs gerando o seu map no futuro.

saoj wrote:Não entendi.

Vc vai passar o objeto de negócio Produto ou vai passar um ProdutoDTO. Mesma coisa para o CarrinhoDeCompras.

A comunicação entre sistemas deve ser feita via JSON ou XML. O que se faz é usar DTO como TEMPLATE para FORMATAR essa resposta. Meu ponto é que o melhor é usar template engine ou um DTO genérico (MAP).

Sergio, o ponto é voce agregar varios objetos num objeto só e fazer uma só chamada com esse objeto. Nao tem nada haver com JSON ou XML e sim como vai ser a interface do servico. Nao tem nada haver com template ou formato.
E nao precisa chamar "ProdutoDTO". Nao tem nenhuma regra.
E DTO generico nao é uma boa idéia, se nao voce perde completamente o sentido de ter uma interface e um contrato.

JavaEvangelist Membro desde: 30/06/2008 13:18:23 Mensagens: 314 Offline

Aqui usamos como Template para relatorios.

JWizard Membro desde: 22/01/2007 22:00:53 Mensagens: 2724 Offline

saoj wrote:Sim, mas vc pode usar um Map que é um DTO genérico para qualquer objeto. Ficar criando um DTO para cada comunicação que vc precisa fazer é overkill.

Como eu falei: acredito que o certo nesse caso é passar os próprios objetos do negócio para a view e ela se encarrega de apresentá-los da maneira que ela quiser via templates, JSP, tags, etc. No meu caso a minha view usava reflection para converter o objeto para JSON, o que poderia ser um problema. Então teria que ter uma camada intermediária para preparar um Maps (DTO genérico) para a view. Mas isso nunca deveria ter sido feito na camada de serviços.

Um map? Não entendi... Se eu tenho uma classe Pessoa com 5 atributos ...

Como vc passaria isso em um map (Sem ser objeto pessoa)?

Supondo uma busca de pessoa por nome, na primeira classe java que recebe o request (servlet/action/sei lah) vc recebe uma chave "nomePessoa" vc fala que é melhor criar um objeto Pessoa e passa-lo para o controle? Já conversaram comigo sobre esse tipo de ação, nunca trabalhei com ele não.

O problema dessa aplicação era o fato de que era algo legado e o framework não tinha como ser atualizado... aí complica né? =/

This message was edited 1 time. Last update was at 12/08/2010 16:08:43

Rubem Azenha wrote:
Sergio, o ponto é voce agregar varios objetos num objeto só e fazer uma só chamada com esse objeto. Nao tem nada haver com JSON ou XML e sim como vai ser a interface do servico. Nao tem nada haver com template ou formato.

Então vc está efetivamente criando mais uma entidade para o seu modelo chamada CarrinhoDeCompras porque alguém precisa receber CarrinhoDeCompra. Vc não está pegando o CarrinhoDeCompra e formatando ele via um CarrinhoDeCompraDTO para que vc possa passá-lo na rede. O problema é usar DTO como TEMPLATE. É o que encontrei no projeto aqui.

Me corrijam se eu estiver errado, mas qualquer formatação pode e deve ser feita com MAPs.

This message was edited 1 time. Last update was at 12/08/2010 16:15:15

jakefrog wrote:

Um map? Não entendi... Se eu tenho uma classe Pessoa com 5 atributos ...
String nome, String sobrenome, int idade, int rg, Filhos[] filhos

Como vc passaria isso em um map (Sem ser objeto pessoa)?

Vc pode converter qualquer objeto em um MAP. Até propriedades que são objetos, arrays, listas, etc. O seu objeto pessoas acima pode ser facilmente convertido num Map. Jogado na rede em JSON ou XML e reconstruído do outro lado.

O ideal seria usar Reflection para fazer isso, mas porque vc pode ter um objeto via Hibernate, cheio de lazy loading, com hierarquia de objetos longa e até ciclica (obrigado Hibernate) vc provavelmente vai querer fazer isso na mão.

This message was edited 1 time. Last update was at 12/08/2010 16:15:23

saoj wrote:
Então vc está efetivamente criando mais uma entidade para o seu modelo chamada CarrinhoDeCompras porque alguém precisa receber CarrinhoDeCompra. Vc não está pegando o CarrinhoDeCompra e formatando ele via um CarrinhoDeCompraDTO para que vc possa passá-lo na rede.

Eu nao estou criando uma entidade nova no sistema... estou criando uma classe. So nao chamei ela pelo sufixo DTO. Voce nao precisa criar uma classe nova, pode ser que a classe ja existe no sistema. Provavelmente nao vai existir, ai vc cria uma nova, mas eu nao acho que ela precisa ser uma entidade e nao acho que ela precisa ter o sufixo DTO.

saoj wrote:
O problema é usar DTO como TEMPLATE. É o que encontrei no projeto aqui. Me corrijam se eu estiver errado, mas qualquer formatação pode e deve ser feita com MAPs.

Nao entendi o que significa DTO como Template. E nao é uma boa ideia usar um Map ao inves do uma classe "de verdade".

*EDIT: Pensando bem, nao é bom reaproveitar classes do sistema para transformar em DTOs... O ideal criar uma classe nova para isso e deixar claro que ele serve apenas para agregar varios objetos numa chamada remota.

Notícias, artigos e o maior fórum brasileiro sobre Java