Aliás, insisto, o melhor é não usar DTO (ou, pelo menos, evitar ao máximo).
[]´s
[quote=Paulo Silveira][quote=“Ruben Azenha”]
Eu nao estou criando uma entidade nova no sistema… estou criando uma classe. So nao chamei ela pelo sufixo DTO.[/quote]
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.
[/quote][/quote]
Perfeito. Lembrando duas coisas:
:arrow: que se vc quer agrupar um monte de coisas para jogar para o outro lado vc pode e deve considerar o uso de COLLECTIONS.
:arrow: 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.
Entendo o seu ponto, mas acho que Maps não introduzem complexidade. Usando reflection vc pode facilitar bastante as coisas.
InjectionUtils.addToMap(map, user, "username", "firstName", "email");
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.
[quote=Rubem Azenha][quote=saoj]
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.[/quote]
Ja que é pra apelar, faz assim na tua classe:
public static Object executa(Map parametros, String nomeServico)Limpo e flexivel.[/quote]
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.
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.
[quote=garcia-jj]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.
[/quote]
Acho que vc se empolgou.
Sim. Essa é a definição. Mas quando vc vê alguém fazendo isso:
List<UserDTO> users = searchUsers( ... )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.
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.
[quote=Paulo Silveira][quote=Rubem Azenha]
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. [/quote][/quote]
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… :shock:
Ou então campos mn_processo, ds_processo, dt_processo. :shock:
Mas quando aos DTOs, se eu não usar sufixo, fico com classes com o mesmo nome. Exemplo: Usuario (entidade), Usuario (DTO), UsuarioDetalhe (DTO). :shock:
No caso de cliente Flex com BlazeDs, usar DTO nao seria o mais adequado?
Depende![/resposta padrão]
A questão é trafegar dados entre duas aplicações, e o custo de cada uma dessas chamadas remotas, que é bem caro. Se tiver que gastar mais de uma chamada p/ transferir um conjunto de dados, e houver a necessidade de diminuir este custo, aí empacotar os objetos(somente o mínimo de dados necessários) em um DTO pode valer a pena.
Senão, beleza, pode continuar como já está.
A sim, tinha esquecido de falar.
No livro que ainda estou lendo (EJB3 In Action) o autor fala que quando tratamos com XML (E não DTO ou Objeto) o processamento da máquina cai muito.
Que chega a ser inviável em alguns casos.
[quote=jakefrog]A sim, tinha esquecido de falar.
No livro que ainda estou lendo (EJB3 In Action) o autor fala que quando tratamos com XML (E não DTO ou Objeto) o processamento da máquina cai muito.
Que chega a ser inviável em alguns casos.[/quote]
Me diga quem é o autor, pra que eu possa falar bastante mal dele =P
Esse autor nunca ouviu falar de web services, não???
[quote=asaudate][quote=jakefrog]A sim, tinha esquecido de falar.
No livro que ainda estou lendo (EJB3 In Action) o autor fala que quando tratamos com XML (E não DTO ou Objeto) o processamento da máquina cai muito.
Que chega a ser inviável em alguns casos.[/quote]
Me diga quem é o autor, pra que eu possa falar bastante mal dele =P
Esse autor nunca ouviu falar de web services, não???[/quote]
Bem, não entendo muito mas… Como é o relacionamento de EJB com Web Service? Não sei te falar exatamente o pq ainda, mas sei que está aí o problema. [=
Esse assunto de XML lento ou não é bem off-topic, mas vamos lá. Sim, o webservice é mais pesado que você usar EJB remoto, por exemplo. Nos projetos na qual eu participo sempre aconselho o pessoal a usar webservice se você precisa realmente trabalhar com transporte via HTTP ou então comunicação entre projetos de linguagens diferentes. Se for um projeto full-Java indico a usar EJB.
Off topic né não. Pq uma das soluções apresentadas aqui, para não se usar DTO, foi usar XML. 
Off topic né não. Pq uma das soluções apresentadas aqui, para não se usar DTO, foi usar XML. ^_^[/quote]
What the fuck? :? Como assim? Que non sequitur é esse?
Bom, é off-topic mesmo. Mas, só pra falar um pouco… eu sou consultor SOA (ou seja, eu trabalho com web services o tempo inteiro). E, mesmo assim, no momento estou trabalhando numa aplicação que precisa de baixíssimo tempo de resposta (do tipo: faz qualquer um arregalar os olhos). Dá- se um jeito 
[]´s
Off topic né não. Pq uma das soluções apresentadas aqui, para não se usar DTO, foi usar XML. ^_^[/quote]
DTO não tem nada a ver com XML e vice-versa. DTO é apenas uma classe que serve para transporte de dados. XML/Webservices serve para outra coisa
Off topic né não. Pq uma das soluções apresentadas aqui, para não se usar DTO, foi usar XML. ^_^[/quote]
DTO não tem nada a ver com XML e vice-versa. DTO é apenas uma classe que serve para transporte de dados. XML/Webservices serve para outra coisa :)[/quote]
Eu sei mano. Oq foi dito lah no começo deste tópico foi. Ao invés de usar DTO usar um MAP ou um XML. É isso q eu to falando.
Ao invés de passar ClienteDTO passar e assim vai…