DTO: Por que usar uma coisa dessas?

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

rjava2010 wrote: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á.

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

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.

jakefrog wrote: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.

Me diga quem é o autor, pra que eu possa falar bastante mal dele =P

Esse autor nunca ouviu falar de web services, não???

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

asaudate wrote:

jakefrog wrote: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.

Me diga quem é o autor, pra que eu possa falar bastante mal dele =P

Esse autor nunca ouviu falar de web services, não???

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.

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

garcia-jj wrote: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. ^_^

JWizard Membro desde: 18/02/2008 16:17:53 Mensagens: 2981 Offline

jakefrog wrote:

garcia-jj wrote: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. ^_^

What the fuck?

Como assim? Que non sequitur é esse?

garcia-jj wrote: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.

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 altíssimo tempo de resposta (do tipo: faz qualquer um arregalar os olhos). Dá- se um jeito

[]´s

jakefrog wrote:

garcia-jj wrote: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. ^_^

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

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

garcia-jj wrote:

jakefrog wrote:

garcia-jj wrote: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. ^_^

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

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 <cliente><nome> e assim vai...

jakefrog wrote:

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 <cliente><nome> e assim vai...

Para a comunicação, seja lá o que vc estiver usando vai ter que ser convertido para XML, JSON, Java Serialization, XXXX.

Isso não tem nada haver com DTO. O ponto do Map foi:

Um Map pode ser convertido tão bem quanto um DTO para um desses acima. Se vc quer apenas agrupar um monte de coisas para jogar para o outro lado, vc pode usar uma Collection pra isso, não precisa criar um objeto agrupador.

Mas isso vai cair no gosto de cada um. Usar um DTO tem vantagens e desvantagens, assim como um MAP. Eu não gosto de ter um milhão de DTO's na minha aplicação. Vai ter algum esperto que vai jogar eles no meio da lógica e cagar tudo. Eu prefiro MAP. Mas use o que vc preferir e seja feliz ! Acho que não é pecado nem um nem outro...

JavaChild Membro desde: 21/06/2007 16:05:01 Mensagens: 142 Offline

Acredito que usar Map, resolve... mas não acredito que seja a melhor solução...
pois como foi falado anteriormente (no forum guj) quando eu coloco alguma coisa no Map, eu não sei nem o que se "esta la dentro", a não ser que eu saiba o que "eu coloquei", eu não vou ter um map.getNome(), map.getIdade(); isso pode quebrar o contrato da aplicação e nunca vai dar um erro de compilação se eu errar a grafia (se eu usar MAP e passar name ao inves de nome, não da erro nem nada , ai o cara se perde aos poucos . a O.O se perde...)

Alem que a programação fica massante e redundante...
o cara faz...:

List<Cliente> clientes = dao.listAll();
List<Map> clienteMap = new ArrayList<Map>();
... dai vcs sabem o resto...(um new map >> alimenta map >> add into list)
código procedural...

e sem falar que a refatoração fica impossivel, se eu quise mudar um nome de algum atributo do cliente... tenho que sair catando os maps, e ir mundando as strings... isso é chato...

Map é uma solução rápida, mais não eficiente...
Bem na minha humilde opinião. =)

Debugger Membro desde: 04/06/2004 09:58:06 Mensagens: 51 Offline

Acho que o pessoal está confundindo Alhos com Bugalhos...

Alguns conceitos para embasar meus argumentos:

DTO => É uma "classe/estrutura de dados", serve para: Estruturar dados... Um Map também é uma estrutura de dados... Ambos podem ser usados nas mesmas situações (e devem ser usados apenas em situações bem especĩficas).

XML => eXtensible Markup Language... No contexto da thread serve apenas como formato no qual os dados transitarão na rede... Não compete nem com os mapas, nem com os DTO's... Ambos podem ser serializados em XML, para transitar na rede. (Normalmente eu uso JSON pq é bem menos verboso).

Fujam de DTO, a não ser quando eles forem usados na fronteira entre duas camadas heterogêneas, em termos de máquinas, ou tecnologia ou coisas assim... Ou seja: Só use DTO's quando precisar estabelecer uma barreira bem clara para os seus objetos de negócio (a causa dessa fronteira pode ser um requisito de segurança, máquinas diferentes, tecnologias diferentes...). Não os use para tráfegar dados dentro da fronteira da sua própria aplicação...

diogopontual wrote:
Fujam de DTO, a não ser quando eles forem usados na fronteira entre duas camadas heterogêneas, em termos de máquinas, ou tecnologia ou coisas assim... Ou seja: Só use DTO's quando precisar estabelecer uma barreira bem clara para os seus objetos de negócio (a causa dessa fronteira pode ser um requisito de segurança, máquinas diferentes, tecnologias diferentes...). Não os use para tráfegar dados dentro da fronteira da sua própria aplicação...

Falou bonito Diogo !!! Bom encontrar pessoas que conseguem entender o nosso ponto de vista. Concordo que no meu caso, em todos os aspectos mundanos, isso é raro. O que pode ser bom... ou não...

Minha resposta ao Ricardo:

Posso estar enganado, mas acho que os benefícios apontados pelo Ricardo são ilusórios. Por que?

Acredito que usar Map, resolve... mas não acredito que seja a melhor solução...
pois como foi falado anteriormente (no forum guj) quando eu coloco alguma coisa no Map, eu não sei nem o que se "esta la dentro", a não ser que eu saiba o que "eu coloquei", eu não vou ter um map.getNome(), map.getIdade(); isso pode quebrar o contrato da aplicação e nunca vai dar um erro de compilação se eu errar a grafia (se eu usar MAP e passar name ao inves de nome, não da erro nem nada , ai o cara se perde aos poucos . a O.O se perde...)

Não, o OO não se perde mas sai ganhando. Porque vc fica obrigado a usar as entidades na lógica e não um monte de DTO ou MAPs. Não é para usar DTO nem MAP na lógica e sim usar os domain objects (User, Product, etc). Se vc concorda com isso, então a tarefa de FORMATAR o resultado passa a ser da ACTION ou da VIEW. No caso aqui estamos falando de JSON, então cada resposta em JSON terá que ser formatada por um DTO diferente. Talvez vc consiga reutilizar um ou outro, mas vai se tornar uma bagunça de DTOs. O benefício que vc citou de refatoração não se aplica, porque se vc muda "nome" para "name", vc vai ter que se lembrar de ir lá nos DTOs e mudar getNome por getName. Isso na mão. Ou não? Logo não vejo diferença em usar um MAP. Teria diferença se o seu DTO estivesse espalhado pela aplicação inteira, mas aí o problema seria outro.

Alem que a programação fica massante e redundante...
o cara faz...:
List<Cliente> clientes = dao.listAll();
List<Map> clienteMap = new ArrayList<Map>();
... dai vcs sabem o resto...(um new map >> alimenta map >> add into list)
código procedural...

Então vc prefere que o DAO já retorne um DTO ??? Errado e impossível, porque dependendo da action / request o cliente vai ter que ser convertido para um DTO diferente. Vc pode ter uns esquemas bem espertos para popular um MAP a partir de um BEAN, pegando só as propriedades que lhe interessam. Usando DTO vc terá que fazer a mesma coisa, pois na minha opinião um DAO nunca deveria retornar um DTO (incluindo MAP que é um DTO genérico).

e sem falar que a refatoração fica impossivel, se eu quise mudar um nome de algum atributo do cliente... tenho que sair catando os maps, e ir mundando as strings... isso é chato...

Posso não estar vendo alguma coisa, mas na minha cabeça com DTO vc tb não tem refatoração. DTO é uma coisa burra, sem lógica, que serve apenas para ESPECIFICAR um objeto. Se o cliente passa a esperar nome ao invés de name, então vc vai ter que catar todos os DTO's que possuem getName e trocá-los para getNome.

Acho que a confusão parte do seguinte: Não estou propondo usar MAP em tudo que é lugar. Isso realmente seria péssimo. Proponho usar um MAP na hora de FORMATAR um resultado, ou seja, no ULTIMO passo do processo, assim como um JSP é o último passo do processo. Lembrando que isso só se aplica para JSON por cause do problema do lazy loading com reflection.

O que não estou vendo? (posso estar errado)

PS: No final, o Ricardo teve uma idéia melhor do que um MAP. Um BeanView que implementa Map. Por que tem que implementar Map ??? Por que o danado do JSON-LIB sabe transformar map em Json. Mas se não for mapa ele vai procurar por getters pensando que é um DTO. Ou seja, o proprio JSON-LIB, por querer ou sem querer, já assume que vai ter gente usando MAP como DTO genérico.

This message was edited 3 times. Last update was at 31/08/2010 02:05:21

Diogo wrote:
Ou seja: Só use DTO's quando precisar estabelecer uma barreira bem clara para os seus objetos de negócio (a causa dessa fronteira pode ser um requisito de segurança, máquinas diferentes, tecnologias diferentes...)

Só para colocar um pouco mais lenha nessa fogueira, pelo menos no meu caso, a causa que determinou a necessidade de usar DTOs foi:

Lazy-loading do Hibernate que faz com que o banco todo seja carregado na view (exagerando claro), dependências cíclicas gerando loop infinito que de alguma maneira surgiu no modelo por culpa do hibernate e do maluco que fez a relação ManyToMany (eu diria por culpa dos dois). O fato inevitável de que para renderizar em JSON o JSON-LIB usa reflection procurando por getters, quando não é map.

Conclusão: como o Diogo falou fuja de DTO sempre que possível. E eu deixo mais uma dica. Se beber muito da mágica do Hibernate não dirija. Ou use iBatis ou JDBC + um query builder/helper.

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