Conceitos: JavaBeans, Pojo, VO e DTO

http://www.guj.com.br/posts/list/23944.java

pedromv:

Olá galera do GUJ.

Estou com dúvidas conceituais sobre os 4 termos citados no título. Afinal de contas, quais são as diferenças e semelhanças entre essa sopa de letrinhas que eu citei? O que significa cada um desses termos e onde são usados?

Gostaria de pedir para que ninguém respondesse no “achismo”, pois isso já aconteceu em outros tópicos relacionados e no fim das contas eu não consegui sanar minha dúvida.

Grato

VO = Value Object. Objeto de valor. É um objeto normalmente imutável (não tem set) que serve para conter um valor. Exemplos: Integer, BigDecimal (outros exemplos incluir os design patterns Money e Range)

DTO ou apenas TO = (Data) Transfer Object. Objecto de transferencia. Serve para enviar dados entre camadas do sistema que podem ou não estar na mesma máquina. São Serializáveis.

POJO = Plain Old Java Object (Velho e Simples Objecto Java) é um referencia a objectos que não dependem da herança de interfaces ou classes de frameworks externos.

JavaBean = Padrão para escrever objetos que contém estado. É uma especificação. Algumas coisas necessárias são : Construtor publico sem argumentos e metodos de acesso começam com set/get, mas tem mais.

Resumo bom…mas acho que o POJO e o VO estao errados…Ou nao?!

Obrigado, Sérgio

Alguém mais concorda ou discorda do Sérgio?

Alexandre, o que você acha que é? Posta aí pra podermos discutir e chegar a uma conclusão

Abraços

Estão corretos exceto que JavaBeans, na verdade, é uma especificação de modelo de componentes manipuláveis por intefaces gráficas falida e que o nome é utilizado hoje vulgarmente para qualquer coisa que obedeça a nomenclatura de get/set.

Javabean é um componente de software reusável, normalmente usado em aplicações standalone e applets.
Possui característas distintas, das quais suas funcionalidades principais consistem em:
Instrospecção, customização, eventos, propriedades e persistência.

Só não entendi o que o calcado escreveu: “Interface gráfica falida”.

É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html

Esclarecendo:
Suponho que diz que VO está errado poruqe vc associa VO como sendo a mesma coisa que DTO. Na verdade isso é um erro histórico que não é mais correto. No principio dos tempos DTO era sinónimo de VO, mas também era sinónimo de muitas outras coisas. Várias tecnologias usavam o termo DTO para se referirem a coisas diferentes. Então o termo DTO transformou-se num problema e atualmente considerado obsuleto. Para subtituir veio o termo TO que não deixa duvidas do que é. O termo VO tem realmente outro significado que não é sinónimo deste. Veja http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

Então , hoje em dia, o correto é usar os termos TO e VO e não DTO pq causa confusão.

Quanto ao POJO não sei por quê você acha que possa estar errado. Veja http://en.wikipedia.org/wiki/Plain_Old_Java_Object

Olá

Leia o blog do Phillip Calçado para entender porque raramente se usa VO e TO do jeito descrito nos design patterns da Sun.

[]s
Luca

Luca:

Olá

Leia o blog do Phillipe Calçado para entender porque raramente se usa VO e TO do jeito descrito nos design patterns da Sun.

[]s
Luca

Qual blog ?
A pergunta era sobre conceitos , não sobre uso

sergiotaborda:

É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html

Sérgio,

Em teoria eu concordo com você mas não existe mais o conceito de javaBeans há anos. Se quem criou a especificação foi a primeira a chamar classes com get/set de bean não há o que discutir.

pcalcado:

sergiotaborda:

É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html

Sérgio,

Em teoria eu concordo com você mas não existe mais o conceito de javaBeans há anos. Se quem criou a especificação foi a primeira a chamar classes com get/set de bean não há o que discutir.

Conceitos não deixam de existir… isso é anacrónico.
Podem deixar de ser usados, ou evoluir, mas não deixam de existir.
JavaBeans é umas especificação. Todos os componentes Swing são JavaBeans (não deixou de ser usado). O cara perguntou o conceito. O conceito é isso ai que está no link.

O detalhe importante é que um javabean não é algo que tem get/set, é algo que lança eventos quando o seu estado muda (ou seja, todos os set lançam eventos). É isso que diferencia um JavaBean de um POJO

No caso da tua definição, nenhum dos componentes do Swing são javabeans, porque eventos e setter não estão atrelados. Uma propertie não precisa suportar notificação, assim como um evento não precisa estar associado somente a propriedades.

Fora isso, a forma como era usada em 98, quando o JBF foi criado já morreu, é uma especificação morta, são conceitos mortos. Você pode continuar pensando em 98, mas não reclame quando as pessoas te acharem estranho por não usar o entendimento contemporâneo destes conceitos.

Bom, Sérgio, basta você discutir com a Sun que foi quem especificou.

Olhe esses links:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPBeans2.html#63735
http://java.sun.com/j2ee/tutorial/1_3-fcs/examples/src/web/bookstore2/util/Currency.java

Quem criou o conceito tem o direito de alterá-lo

Eu acho importante mencionar a especificação falida do JavaBeans mas não adianta dar murro em ponta de faca, a ‘comunidade’ já estragou o conceito faz muito tempo.

pcalcado:

Bom, Sérgio, basta você discutir com a Sun que foi quem especificou.

Olhe esses links:

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPBeans2.html#63735
http://java.sun.com/j2ee/tutorial/1_3-fcs/examples/src/web/bookstore2/util/Currency.java

Quem criou o conceito tem o direito de alterá-lo

Eu acho importante mencionar a especificação falida do JavaBeans mas não adianta dar murro em ponta de faca, a ‘comunidade’ já estragou o conceito faz muito tempo.

Vc é muito engraçado. Citar a specificação do java EE 1.3 … não tem nada mais recente ? Algo que se possa aceitar que é atual ? … talvez http://java.sun.com/j2se/1.5.0/docs/guide/beans/index.html

A "comunidade"já estragou o conceito… certo ainda bem que eu não faço parte dela … ela vai ficar muito triste quando souber que o NetBeans funciona com base em JavaBeans. É tão importante que vc pode colocar os seus proprios http://www.cin.ufpe.br/~phmb/ip/MaterialDeEnsino/JavaBeans/RoteiroJavaBeansEclipse3/rot_NetBeans.html
… parece que continuam “dando murro em ponta de faca”

louds:

sergiotaborda:

O detalhe importante é que um javabean não é algo que tem get/set, é algo que lança eventos quando o seu estado muda (ou seja, todos os set lançam eventos). É isso que diferencia um JavaBean de um POJO

No caso da tua definição, nenhum dos componentes do Swing são javabeans, porque eventos e setter não estão atrelados.

Suponho que “atrelados” significa ter listeners registrados.
Ninguem disse que tinham que ter (embora esteja subentendido que tem que ter uma forma de os registrar… ). Eu falei em lançar o evento, não se falou em capturar esse evento pq ,1) é dificil capturar sem lançar primeiro,2) a captura é responsabilidade de outro objecto que ninguem exige que seja um JavaBean)

Não precisa. Mas precisa para manter o padrão.
É como ter um construtor sem argumentos. Tem que ter para manter o padrão, mas não tem-que-ter-ou-o-mundo-vai-acabar tem-que-ter
Se vc não quer que tenha, ninguem o obriga.

Fora isso, a forma como era usada em 98, quando o JBF foi criado já morreu, é uma especificação morta, são conceitos mortos. Você pode continuar pensando em 98, mas não reclame quando as pessoas te acharem estranho por não usar o entendimento contemporâneo destes conceitos.

Ninguem perguntou se era viva, apenas se perguntou o que era.
Ao menos agora o colega que perguntou sabe que é/era uma especificação.

Mas é bom saber que ninguem use a o pacote java.beans que os componentes swing não lançam java.beans.PropertyChangeEvent quando as suas propriedades são alteradas. :shock:

E a pergunta que não quer calar é :roll: : se o objecto lança um evento e ninguem está lá para o ouvir, será que o evento foi mesmo lançado ?

Ai ai ai…

Antes de mais nada, um pouco de cortesia faz muito bem, você não está brigando, amiguinho, está debatendo.

Quando a spec 1.3 era o estado da arte em java a spec de JavaBeans já existia há séculos então qual o seu ponto? Que a sun (ou o JCP, ou zahl) errou ao definir que aquele Currency é um bean e se consertou depois? Será?

Não importa. pegue qualquer versão de container JSP que quiser e tente utilizar uma classe não serializável (logo não JavaBean) como “JavaBean” em uma JSP. Funciona e a própria Sun está cheia de documentação dizendo que funciona.Isso é dar murro em ponta de faca.

Mas não, não acredite em mim. Java EE 1.3 é velho? Leia a 1.5:

Enquanto estiver no site baixe a aplicação exemplo e veja os beans dela. Vair ver o exemplo de JavaBean:

Além de um péssimo design isso não é um JavaBean. Mas se a Sun/JCP diz que é vira consenso da indústria, afinal eles inventaram a primeira spec.

Se você parar para ler uma linha do que eu ou o Rodrigo escrevemos antes de responder vai perceber que nós não discordamos de você, só que o termo se prostituiu pelos próprios inventores. Eu realmente acho que o modo como se justifica o design ruim de uma classe ao chamá-la de ‘bean’ é patético, mas eu já desisti. Não dá para argumentar que algo não é um bean quando a documentação oficial diz exatametne o contrário.

Se você quer ser um ortodoxo JavaBean boa sorte, a Sun e o JCP dizem todo dia que um javaBean tem get/set com um construtor vazio e pronto (antigamente tinha que ser serializável, hoje em dia nem isso).

Quanto a sua consideração de desnvincular JavaBeans de ferramentas visuais…adivinhe? A Sun também discorda de você:

É uma definição ambígua, é uma porcaria mas não foi eu quem inventou, dirija seus comentários engraçadinhos a outra pessoa ou entidade.

Ok pessoal.

tudo que tem get/set vamos chamar somente de Bean e todos ficam felizes para sempre.

Este assunto deu pano pra manga…

Abraços a todos e não se esqueçam:
DTO é coisa do passado e JavaBean…?!.

pcalcado:

Ai ai ai…

Continuo sem ver onde naqueles texto está escrito que JavaBeans é uma especificação ultrapassada/morta/obsuleta etc… Tb não vejo onde diz lá que componentes swing não são javabeans nem onde diz que o netbeans não é baseado em javabeans.

Mas se realmente é verdade isso, então qual é o modelo de componentes do java usado pelo netbeans ?

Sergio, ninguém não falou que os componentes swing não são JavaBeans. Eu fui irônico, pq você disse que todas propriedades deveriam suportar notificação, mas não era o ponto.

Quanto a ser uma spec morta. Bom, isso ela é. Se o NetBeans é baseado no JBF, bom, isso é um legado de uma ferramenta que tem quase uma década. Quanto ao uso de Javabeans estar morto, pelo contrário, uma enorme quantidade de ferramentas usam JavaBeans, mas cunhando como o termo apenas um objeto com construtor vazio e getters/setters.

Você pode ver que JBF foi uma idéia burra que não deu certo, a idéia era competir com o mercado de componentes para delphi. Me diz quantos pacotes de JavaBeans são distribuidos/vendido por ISVs?

Fora isso, o Netbeans hoje usa um mecanismo de abstração muito mais útil que componentes, que são os plugins e suas extensões. Isso sim é util e funcional, mas componentes como JavaBeans e perda de tempo.