DTO: Por que usar uma coisa dessas?

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

Rubem Azenha wrote:

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.

Uma classe que representa alguma coisa concreta: CarrinhoDeCompra. Se ela vai ser persistida no banco de dados ou não, não interessa muito. Por que vc não quer chamá-la de entidade? Um carrinho de compras é uma entidade. Se você quer criar apenas um AGRUPADOR de coisas, então use COLLECTIONS.

Rubem Azenha wrote:

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".

Por que? Melhor usar um MAP do que usar um CarrinhoDeCompraDTO, ou seja, um mero formatador para o CarrinhoDeCompra. Consigo ver algumas vantagens de usar DTO. Type checking. As propriedades são métodos e não Strings como Maps, etc. Mas ainda fico com a flexibilidade e limpeza dos Maps.

bestlinux wrote:Aqui usamos como Template para relatorios.

Se vc quer usar DTO como template para exibir objetos, tudo bem. É factível. Eu consideraria primeiro MAPs e TEMPLATE ENGINE. O Map é um DTO genérico muito poderoso e flexível.

Agora NUNCA meter DTO no meio dos serviços, algo to tipo como encontrei aqui:

Rubem Azenha wrote:
Eu nao estou criando uma entidade nova no sistema... estou criando uma classe. So nao chamei ela pelo sufixo DTO.

Eu gosto dessa abordagem do Azenha: nao usar sufixo. Evita-los ao maximo.

As vantagens em relacao ao Map sao as que voce mesmo citou: ganha type safety e clareza quando for ler codigo de outra pessoa. Ficar jogando Map de um lado pro outros vai fazer a gente trabalhar com a famosa POS: Programacao orientada a strings. Map voce ganha flexibilidade, e de quebra, complexidade para manter. A escolha é sua.

O ponto importante é so lembrar de usar DTO quando tem inumeras invocacoes remotas que poderiam ser feitas tudo numa so. E, como o Azenha ja frisou, nao tem pra que usar o sufixo DTO.

Li toda a discusão e não entendi essa cisma em usar MAP para gerar XML e JSON recorrendo a reflection para buscar os campos, vc vai converter um objeto inteiro para transmitir inclusive usa hierarquia? Acreido que seria a hora de migrar a aplicação para MongoDB ou Couch...

Eu não preciso criar um CarrinhoDeComprasDTO, só crio um CarrinhoDeCompras e ele não vai ser perssisto, vc substituiria isso:

Só ilustrando o que eu entendi dos posts do Rubem (se eu entendi errado por favor me corriga), pra usar um MAP ou COLLECTION?

Me diga vou perder legibilidade e conseguetemente TypeSafe por qual motivo?

saoj wrote:

Por que? Melhor usar um MAP do que usar um CarrinhoDeCompraDTO, ou seja, um mero formatador para o CarrinhoDeCompra. Consigo ver algumas vantagens de usar DTO. Type checking. As propriedades são métodos e não Strings como Maps, etc. Mas ainda fico com a flexibilidade e limpeza dos Maps.

Ja que é pra apelar, faz assim na tua classe:

Limpo e flexivel.

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

Paulo Silveira wrote:O ponto importante é so lembrar de usar DTO quando tem inumeras invocacoes remotas que poderiam ser feitas tudo numa so. E, como o Azenha ja frisou, nao tem pra que usar o sufixo DTO.

Aliás, insisto, o melhor é não usar DTO (ou, pelo menos, evitar ao máximo).

[]´s

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

Paulo Silveira wrote:

Ruben Azenha wrote:
Eu nao estou criando uma entidade nova no sistema... estou criando uma classe. So nao chamei ela pelo sufixo DTO.

Eu gosto dessa abordagem do Azenha: nao usar sufixo. Evita-los ao maximo.

O ponto importante é so lembrar de usar DTO quando tem inumeras invocacoes remotas que poderiam ser feitas tudo numa so. E, como o Azenha ja frisou, nao tem pra que usar o sufixo DTO.

Perfeito. Lembrando duas coisas:

que se vc quer agrupar um monte de coisas para jogar para o outro lado vc pode e deve considerar o uso de COLLECTIONS.

no caso do CarrinhoDeCompras, a chance é grande desse cara virar um objeto do modelo de negócios. Então ele merece uma classe pra ele que não tem nada haver com DTO.

Paulo Silveira wrote:
As vantagens em relacao ao Map sao as que voce mesmo citou: ganha type safety e clareza quando for ler codigo de outra pessoa. Ficar jogando Map de um lado pro outros vai fazer a gente trabalhar com a famosa POS: Programacao orientada a strings. Map voce ganha flexibilidade, e de quebra, complexidade para manter. A escolha é sua.

Entendo o seu ponto, mas acho que Maps não introduzem complexidade. Usando reflection vc pode facilitar bastante as coisas.

Imagine a situação onde vc tem duas páginas, ou dois web services: São idênticos, mas um espera dateOfBirth e o outro espera birthDate. Vc vai criar um novo DTO só por causa disso. Com Map isso se torna ridículo. Eu gosto dessa flexibilidade.

Rubem Azenha wrote:

saoj wrote:

Por que? Melhor usar um MAP do que usar um CarrinhoDeCompraDTO, ou seja, um mero formatador para o CarrinhoDeCompra. Consigo ver algumas vantagens de usar DTO. Type checking. As propriedades são métodos e não Strings como Maps, etc. Mas ainda fico com a flexibilidade e limpeza dos Maps.

Ja que é pra apelar, faz assim na tua classe:

public static Object executa(Map parametros, String nomeServico)

Limpo e flexivel.

Hehehe. Engraçado. Mas não. Me refiro apenas para quando vc tem que TRANSMITIR dados de um lado para o outro. Ou formatá-los.

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

ja deu pra ver que isso é uma questão de opinião... mas como isso aqui é um fórum de discussão, a minha é que o map sem duvida deixa mais versatil, porém tem um outro lado negativo, tabalhando com uma classe, ou melhor... com uma interface, você sabe exatamente o que esperar... você vai ter um metodo getXXX por exemplo, que vai te retornar a informação xxx... ok, com a classe você sabe exatamente o que você pode ter nela... com o mapa você pode ter qualquer coisa la... claro que você pode num exemplo simplista iterar a chave e saber todos os pares de chave/valor que tem la, mas isso é bem mais complicado, fica um código mais sujo, fora de padrão, que você só sabe o que tem la realmente em tempo de execução, diferente de usar uma classe DTO...
Numa boa, você até pode criar um "util" para trabalhar com o seu mapa que se refere a alguma coisa trafegada... mas isso parece simplificar alguma coisa? Ao menos não para mim...

quanto a usar o sufixo DTO ou mesmo VO, eu acho um tanto relativo... quando você tem um web service por exemplo para trocar informações com parceiros, tem até uma probabilidade alta de que quando o seu parceiro veja que você está retornando para ele um objeto Boleto, por exemplo, ele deduza que seja um VO, mas pode ser que ele não deduza isso, então o sufixo VO torna essa possibilidade dele entender isso mais fácil (e a poluição gerada é pequena, ao menos na minha opinião, sendo trocada essa poluição por um código mais fácil de entender), por isso eu sou a favor de se utilizar este sufixo "dependendo do escopo do projeto".

Impressionante como o pessoal quer programar em Java como se fosse PHP. Todo mês aparece aqui no GUJ algum tópico de alguém reclamando de lazy-load e DTOs. Mas o mais incrivel é ver que falam sem mesmo conhecer para que serve realmente um DTO.

Obvio que o principal fundamento do DTO é para trabalhar com aplicações onde você possui módulos EJB remoto. Porém mesmo em aplicações onde você não possui a separação de projetos eu prefiro usar o DTO, pois assim eu entrego para a camada client os dados já formatados e carrego somente (e tudo) o que eu preciso.

Eu já havia escrito isso há algum tempo, quando um usuário do Vraptor reclamou do lazy-exception. Lendo esse post dá para entender bem porque os DTOs são necessários. http://guj.com.br/posts/list/15/204519.java#1039241

Agora quando ao sufixo DTO eu uso para diferenciar uma entidade Customer dos seus DTOs CustomerDTO e CustomerDetailsDTO, assim como uso CustomerBean e CustomerRemote no nome dos EJBs. Mas creio que isso seja uma questão de gosto.

garcia-jj wrote:Impressionante como o pessoal quer programar em Java como se fosse PHP. Todo mês aparece aqui no GUJ algum tópico de alguém reclamando de lazy-load e DTOs. Mas o mais incrivel é ver que falam sem mesmo conhecer para que serve realmente um DTO.

Acho que vc se empolgou.

Obvio que o principal fundamento do DTO é para trabalhar com aplicações onde você possui módulos EJB remoto. Porém mesmo em aplicações onde você não possui a separação de projetos eu prefiro usar o DTO, pois assim eu entrego para a camada client os dados já formatados e carrego somente (e tudo) o que eu preciso.

Sim. Essa é a definição. Mas quando vc vê alguém fazendo isso:

Vc percebe que o cara não entendeu DTO.

Continuo achando melhor usar Map do que DTO. Não gosto de ter um milhão de DTOs. Como dei o exemplo. Se um serviço requer a mesma resposta, com apenas uma propriedade diferente, exemplo: username tem que sair e entrar gamertag, então vc vai ter que fazer um novo DTO só para isso, quando se vc estivesse usando um Map, a coisa seria ridícula.

E Lazy loading pode ser um saco, principalmente quando vc tem relações ManyToMany cíclicas. E pelo jeito não sou o único que reclama. Mas o Hibernate oferece muitas outras vantagens que vale a pena passar por cima disso. Pelo jeito não sou o único que não gosta de lazy loading.

saoj wrote:Continuo achando melhor usar Map do que DTO. Não gosto de ter um milhão de DTOs. Como dei o exemplo. Se um serviço requer a mesma resposta, com apenas uma propriedade diferente, exemplo: username tem que sair e entrar gamertag, então vc vai ter que fazer um novo DTO só para isso, quando se vc estivesse usando um Map, a coisa seria ridícula.

Sérgio, entendi seu ponto de vista. Só penso que usando Map você perde a tipagem, e também você não sabe o que você tem no seu objeto sem fazer instrospecção ou ler a documentação. Em um DTO se você tem uma propriedade UserDTO.getNome você de cara vê que é o nome. Além disso em alguns momentos você pode precisar fazer type-cast, além de que você deixa uma margem para que alguém por engano mande um String ao invés de um Date.

Eu tenho usado uma estrutura semelhante ao que a Sun propoe do DTO. Se eu tenho uma entidade User e tenho uma dela de listagem e outra de detalhe eu crio dois DTOs: UserDTO e UserDetailDTO. No UserDTO coloco apenas as propridades que precisa para listagem, e a UserDetailDTO estende UserDTO com as demais propriedades. Isso tem atendido bem meus atuais projetos com EJB remoto.

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

Paulo Silveira wrote:

Rubem Azenha wrote:
O ponto importante é so lembrar de usar DTO quando tem inumeras invocacoes remotas que poderiam ser feitas tudo numa so. E, como o Azenha ja frisou, nao tem pra que usar o sufixo DTO.

bem isto não e nada... pior e em uma empresa que trampei que eles chamavam as tabelas do banco com o sufixo de tb, exemplo: cliente_tb...

luistiagos wrote:bem isto não e nada... pior e em uma empresa que trampei que eles chamavam as tabelas do banco com o sufixo de tb, exemplo: cliente_tb...

Ou então campos mn_processo, ds_processo, dt_processo.

Mas quando aos DTOs, se eu não usar sufixo, fico com classes com o mesmo nome. Exemplo: Usuario (entidade), Usuario (DTO), UsuarioDetalhe (DTO).

Smalltalk Membro desde: 18/08/2010 01:56:44 Mensagens: 1 Offline

No caso de cliente Flex com BlazeDs, usar DTO nao seria o mais adequado?

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