DTO - dúvida conceitual

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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

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!

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4679 Offline

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

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

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!

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

passos wrote:

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

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!

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!

Thiago Senna wrote:
quando se fala de java bean me lembra mais a especicificação de se usar os metodos getAlgumaCoisa, setAlgumaCoisa, isBoolean e por ai vai...

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.

http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Filipe Sabella wrote:Qual o problema de retornar objetos normais, só que apenas com os atributos que você vai usar populados?

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

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

Sorriso wrote:

Filipe Sabella wrote:Qual o problema de retornar objetos normais, só que apenas com os atributos que você vai usar populados?

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

hã ?

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

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!

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

E digo mais... a resposta do Rafael é mesmo muito boa!

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)?

Rafael Ferreira wrote:
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. ?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

rodrigousp wrote:
E, muito importante...
Padrões não são receitas!

Essa teria graça se não fosse triste.
Padrões não são receitas de bolo, realmente. Não são "10 passos para a classe maravilhosa". Isso é verdade.
Mas daí a menosprezar os padrões ... peraí ...
Padrões são coisas série. Ou vc segue ou não segue. Mesmo que vc se sinta inspirado, se vc não segue o padrão à risca,
o que vc obtem não é uma implementação do padrão. O detalhes é saber o que é o "padrão à risca" e isso sim é uma coisas metafisica. Mas isso apenas porque os livros de padrões são catálogos e não teses sobre axiomática.
Vc pode definir os padrões sob a forma de teoremas derivados "matemáticamente" da axiomática de OO. Mas isso seria um texto
chato que 95% das pessoas passaria longe. Com a ideia de que o padrão é uma receita (embora não seja realmente, sim) essas 95% das pessoas pelo menos vão aceitar a ideia.

O que é triste é ter que ler que prototype , mediator e façade são tipos semelhantes de padrões. Essa doeu.
Claro que quem defende que padrões são felxiveis, não são sérios e são meros "guias" dá-se ao luxo de dizer uma coisa dessas.
Para quem acha que padrões são colorários dos axiomas de OO isso equivale a dizer que a operação de soma, divisão e conjugação são tipos semelhantes de operação...

This message was edited 1 time. Last update was at 08/08/2008 16:44:32

Existe necessidade de ser agressivo quando se posta no forum???
Juro que não entendi a agressividade gratuita.

De qualquer forma, seu argumento vai de encontro à definição de padrão. Se padrões são soluções recorrentes, identificado em situações diferentes... ninguém estava seguindo nada à risca. Nas palavras do fowler:

"One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity"

.

Padrões são sérios, e são coisas importantes. Mas é preciso entendê-los e não vê-los como receitas.
Um ótimo exemplo disso é o DTO. O padrão fala do problema de usar vários getters e setters entre sistemas distribuídos. Isso seria muito ruim.... Ao invés disso, sugere-se enviar um objeto que encapsule todas essas informações. Ponto.

O padrão não dita que você não pode colocar código de validação, comportamento, etc nos DTOs.

Outro excelente exemplo é o padrão strategy. Sugiro que as pessoas leiam a descrição do padrão e comparem com a idéia de Interface do Java. Observe que no C/C++ e no Smalltalk não existe Interface... O que você acham? O conjunto List + implementações (ArrayList, LinkedList, etc) não implementa o padrão Strategy? Pattern é isso, uma solução recorrente (um conjunto de melhores práticas) para problemas recorrentes.

Aos participantes gostaria de indicar este livro:

REFATORAÇAO PARA PADROES
Autor: KERIEVSKY, JOSHUA
Editora: ARTMED
Assunto: INFORMATICA-PROGRAMAÇAO

O autor aconcelha a ler o livro com a presença de outro livro do Mr. Martin Fowler REFACTORING IMPROVING THE DESIGN OF EXISTING CODE pois ele faz várias referencias sobre este livro.

P.S. O livro é em ingles mas o traduzido está com a qualidade aceitavel, vale a pena dar uma olhada.

Ahhh...já ia esquecendo neste livro não fala de DTO rsrsrsrsr.

flw

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

rs....
engraçadinho...

Ahhh...já ia esquecendo neste livro não fala de python. hahahahah!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

rodrigousp wrote:Existe necessidade de ser agressivo quando se posta no forum???
Juro que não entendi a agressividade gratuita.

Juro que não entendi onde está a agressividade gratuita.

De qualquer forma, seu argumento vai de encontro à definição de padrão. Se padrões são soluções recorrentes, identificado em situações diferentes... ninguém estava seguindo nada à risca. Nas palavras do fowler:

"One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity"

.

Nas minhas próprias palavras:
"Padrões são colorários dos axiomas de OO"

Eles não aparecem do nada como o Fowler expressa , eles está lá sempre.
Se vc seguir as regras OO ( os axiomas , como SoC, IoC , encapsulamento, etc...) vc tem um código enxuto . Mesmo que vc não saiba os nomes dos padrões que acabou de usar, eles estão lá.
Quando vc identifica uma solução isso não acontece porque vc está notou uma coincidencia, e sim porque vc está vendo as regras funcionarem. Elas funcionam sempre da mesma forma e por isso as "coincidencias" são recorrentes.

O padrão não dita que você não pode colocar código de validação, comportamento, etc nos DTOs.

Pois não. Mas regras mais importantes ditam, como o SoC.
O que vc está dizendo é que se eu pegar um pojo da vida o fizer serializable e colocar um monte de codigo de validação, colocar o construtor privado , colocar get/set paras os atributos, colocar um método estático para retornar o objeto que eu crio dando clone de um atributo estático privado e final na classe eu estarei usando : Prototype (clone copy), Factory-Method (método de criação), TO (serializable) e Bean (get/set).
Não. Vc está fazendo apenas uma salada de frutinhas e pior, violando o SoC.
Em suma, se viola o SoC o seu codigo não pode ser considerado bom, muito menos um padrão.

Outro excelente exemplo é o padrão strategy. Sugiro que as pessoas leiam a descrição do padrão e comparem com a idéia de Interface do Java. Observe que no C/C++ e no Smalltalk não existe Interface... O que você acham? O conjunto List + implementações (ArrayList, LinkedList, etc) não implementa o padrão Strategy?

Interfaces são constutos uteis ao padrão strategy, mas não são a "implementação do padrão strategy" isso é absurdo. Strategy pode ser feito com herança normal se não existissem interfaces.
ArrayLisr , etc... sim são estratégias de List que por sua vez é estratégia de Collection. Isso sim. Mas nunca "interface" per se será um padrão.

Como os texto que citou falam : padrão é algo que não existe na linguagem. É algo que vc faz com a linguagem.

Pattern é isso, uma solução recorrente (um conjunto de melhores práticas) para problemas recorrentes.

Padrões não são conjuntos de melhores práticas, são o resultado direto do seguimento coerente dos principios de OO. Quando vc aplica os principios de OO a um problema vc obtem um resultado. Se aplicar de novo os mesmos princípios vc obtem o mesmo resultado. A aplicação dos principios é complexa, por isso vc pula essa fase. Dai quand vc tem um problema vc tem a solução. Mas ela não aparece magicamente.

Um exemplo, a lei de pitagoras para a relação entre os catetos e a hipotenusa de um triangulo retangulo pode ser usada diretamente sem ter que a deduzir a todo o momento. O mesmo que a as leis de newton.
Ou seja, se vc tem um problema vc aplica o que já sabe e obtem um resultado. Vc não perde tempo deduzindo a solução a partir de principios básicos cada vez que tem um problema. Da mesma forma vc não deduz a solução para um problema de OO a cada vez que precisa, vc faz isso as primeiras vezes e depois vc já sabe a solução e aplica. Vc cataloga as soluções para fácil uso e pronto.
As solução advem dos principios. Os padrões são atalhos. Dado um problema o padrão dá a solução. Mas o padrão contêm em si todo o processo de aplicação dos princípios da OO.

Padrão não são receitas de bolo, mas são mais que guias: são corolários. Ou seja, não é possivel, para o mesmo problema encontrar outra solução diferente. Se fosse guias ou receitas poderiam ser encontradas outras formas.

O que temos diferente são as implementações. Ai sim, existem muitas variantes. Mas o padrão não inclui a implementação, por isso a variedade de implementações não afeta em nada a realidade de que o padrão é univocamente definido pelo problema e pela aplicação dos axiomas de OO.

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