Me lembro como se fosse hoje quando tava começando o meu projeto de final de curso e usei a seguinte estrutura
view --> controle --> façade --> negocio --> DTO --> DAO
Fiz diagrama de classes e tudo!!! Achei que eu estava arrasando por que haviam 8 patterns em meu sistema que não tinha tem 10 classes de negócio direito!
Daí eu mostrei para alguns professores, e todos eles me parabenizaram!!
Aff… Fiquei tão orgolhoso!!! :oops:
Abraços!
Thiago
Antes que me perguntem pq fiz isso… eu digo!
Tinha acabado de ler alguns dos capítulos do livro Core J2ee Patterns!
Imaginem um cabeção e mala que nem eu no 3º ano da faculdade diante de um livro desses! Ele chega a pensar que está no paraíso!
Abraços!
Thiago
Mas o DTO não deveria estar entra o controle e o facade ?
view --> controle --> DTO --> façade --> negocio --> DAO
[quote=pcalcado][quote=fabgp2001]
Ai vem uma outra grande pergunta. Quantos projetos sao realmente distribuidos que justifiquem o uso de DTO?
[/quote]
Não repcisa ser um sistema mosntro, mas você está cerot no que acho que tentou dizer: 99% dos posts no GUJ sorbe isso são sistemas que não precisam de DTOs.[/quote]
Isso, mas digo mais, acho que mais de 90% dos sistemas desenvolvidos em Java nao sao distribuidos.
[quote=jprogrammer]Mas o DTO não deveria estar entra o controle e o facade ?
view --> controle --> DTO --> façade --> negocio --> DAO [/quote]
Porque o DTO esta em uma camada se ele so fica zanzando no sistema?
Existem sistemas onde o DTO é criado na View e vai sendo enviado até o DAO, nao entendo o porque dessa distribuicao demostrada ai.
]['s
[quote=fabgp2001]
Isso, mas digo mais, acho que mais de 90% dos sistemas desenvolvidos em Java nao sao distribuidos.[/quote]
Eu também. Mais até, bem mais.
Hoje em dia eu trabalho com cluster e clientes remotos, e mesmo assim em uns dois projetos apenas. De resto, nada justificaria um DTO para aplicações web como as que eu já fiz tantas por aí.
Pelo o que eu li um DTO serve para diminuir a sobrecarga na rede devido a chamadas de métodos remotos, certo? É tipo “zipar” os dados e mandar de uma vez só, em vez de um a um, certo?
E o pessoal confunde e usa DTO para simplesmente para acessar banco de dados, certo? Eu mesmo confundo (ou confundia, sei lá) um pouco, achando que aqueles beans burros que representam as entidades do BD eram DTOs.
Certo???
Na mosca!
A cosia qeu me dá mis medo quando respondendo alguém aqui ou em alguma lsita é:
Onde eles arrumam tanta criatividade?
Jprogrammer… obrigado por me lembrar… a estrutura que eu coloquei tava errada!
Na verdade eu tinha feito assim (Podem acreditar… é sério)
view --> DTO --> controle --> DTO --> façade --> negocio --> DTO --> DAO
Abraços!
Nao só isso, acho que a maior confusao é com as siglas. DTO, VO, Pojo, Java Beans pra muitos isso é tudo igual e sabemos que isso nao é verdade.
Exemplo, quando o Hibernate diz que precisa de POJO pra persistir os objetos, muitos acham que sao obrigados a usar DTO por isso.
]['s
[quote=Fabgp] Nao só isso, acho que a maior confusao é com as siglas. DTO, VO, Pojo, Java Beans pra muitos isso é tudo igual e sabemos que isso nao é verdade.
Exemplo, quando o Hibernate diz que precisa de POJO pra persistir os objetos, muitos acham que sao obrigados a usar DTO por isso. [/quote]
Não é somente isso!
Na verdade, temos o costume de pensar que o ideal é contruir um sistema super flexível há mudanças! E muitos pensam que software flexível é sistema enfestado de patterns!
Daí, a falta de experiência fazem com que nós interpretemos estes patterns (DTO) desta maneira.
O problema é que todo mundo quer sistema flexível. O lógico parece ser que um sistema burocrático é o mais ideal para as mudanças, enquanto metodologias ágeis felizmente traz uma outra abordagem, no qual sistemas flexíveis em mudanças são programas com código simples e com bém testado! (resumidamente)
Abraços!
Só para encher o saco, o Hibernate não precisa hehe só o construtor default é necessário, infelizmente.
E, só para alfinetar:
“Pessoas inventam porcentagens para ganhar credibilidade. 87% das pessoas sabem disso.” - Homer Simpson
:XD:
Pra mim e (e?) tudo a mesma coisa… leio vc precisa de um (cole aqui uma das sopa de letrinhas supracitada) e no final das contas vejo um JavaBean. Não e pra pensar que e tudo a mesma coisa?
Depois de ler esse topico entendi o que e um DTO (eu acho) e que na verdade nao preciso dele pra p* [piiii] nenhuma.
Agora:
VO = DTO?
Pojo = JavaBean?
Deus me livre!
Pra mim e (e?) tudo a mesma coisa… leio vc precisa de um (cole aqui uma das sopa de letrinhas supracitada) e no final das contas vejo um JavaBean. Não e pra pensar que e tudo a mesma coisa?
Depois de ler esse topico entendi o que e um DTO (eu acho) e que na verdade nao preciso dele pra p* [piiii] nenhuma.
Agora:
VO = DTO?
Pojo = JavaBean?
Deus me livre![/quote]
Sim… VO = TO = VO != boas práticas em sistemas não distribuídos!
POJO != Java Bean…
quando se fala de java bean me lembra mais a especicificação de se usar os metodos getAlgumaCoisa, setAlgumaCoisa, isBoolean e por ai vai…
POJO, por sua vez é mais flexível. Pojo nada mais é do que um objeto java simples, sem frescura, sem vaidade, sem batom e sem botox! Se vc vai usar o nome dos métodos igual aos do java bean nele, vc pode fazer isso tranquilamento, assim como muitos fazem!
Mais que isso, JavaBeans é uma especificação de componentes bem adiantadinha pra sua época, mas que não funfou. O que sobrou dela na maiorida das vezes são frameworks que fazem reflection beaseados em set/Get/Construtor vazio e um ou outro uso de BeanInfo.
Na verdade, essa convenção existe mesmo em C++. Não sei se foi influência de Java (sacrilégio!!!), mas que tem tem.
Felipe creio que isso não seja uma boa maneira…o bom é ter o seu objeto sempre completo fica meio estranho voce passar um objeto em que voce só tem um dado, se for assim é preferível retornar um array de string…sei lá o o tipo dos seus dados mas nunca o objeto pela metade…
Felipe creio que isso não seja uma boa maneira…o bom é ter o seu objeto sempre completo fica meio estranho voce passar um objeto em que voce só tem um dado, se for assim é preferível retornar um array de string…sei lá o o tipo dos seus dados mas nunca o objeto pela metade…[/quote]
hã ?
Importante:
DTO não é um javabeans com getters e setters.
DTO não é o mesmo que um Value Object.
DTO não é um anti-padrão, nem o Fowler falou que DTO é um anti-padrão.
Recomendo:
(Re)Ler com atenção o que o Shoes, CV e Fowler (http://martinfowler.com/bliki/AnemicDomainModel.html) escreveram.
E, muito importante…
Padrões não são receitas!
E digo mais… a resposta do Rafael é mesmo muito boa!
[quote]
Agora, faço a seguinte pergunta: Eu devo julgar os padrões pela intenção ou pela “implementação” (isto é, a descrição do Padrão no GoF, “obsessivo” por heranças)?[/quote]
[quote=Rafael Ferreira]
Vou deixar o John Vlissides responder essa:
?It seems you can?t overemphasize that a pattern?s Structure diagram is just an example, not a specification. It portrays the implementation we see most often. As such the Structure diagram will probably have a lot in common with your own implementation, but differences are inevitable and actually desirable. At very least you will rename the participants as appropriate for your domain. Vary the implementation trade-offs, and your implementation might start looking a lot different from the Structure diagram.
As for whether one is following the pattern or not, who cares? The pattern is a means to an end, not an end itself. Following it in any strict sense is immaterial. If the pattern solves your problem directly, that?s great; if you have to bend it a bit, that?s great too. Even if the pattern merely inspires you toward an altogether different solution, it has still proven useful. The only potential problem here lies in the documentation phase, when you?re describing your solution in terms of patterns. You don?t want to mislead someone with irrelevant patterns. If you identify a set of classes as adhering to a pattern, make sure they fulfill the pattern?s intent. If the connection is tenuous, don?t mention the pattern; otherwise you?re sure to confuse more than clarify. ?[/quote]