Conceitos: JavaBeans, Pojo, VO e DTO

[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

[Rafael_Nunes]

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

[sergiotaborda]

[quote=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[/quote]

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.

[Alexandre_Ferreira1]

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

[pedromv]

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

[pcalcado]

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.

[jonataswingeter]

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

[sergiotaborda]

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.

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

[sergiotaborda]

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

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

[Luca]

Olá

Então , hoje em dia, o correto é usar os termos TO e VO

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

[sergiotaborda]

[quote=Luca]Olá

Então , hoje em dia, o correto é usar os termos TO e VO

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[/quote]

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

[pcalcado]

[quote=sergiotaborda]
É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html[/quote]

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.

[sergiotaborda]

[quote=pcalcado][quote=sergiotaborda]
É usado ERRADAMENTE. Veja
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html[/quote]

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.[/quote]

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

[louds]

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.

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

[sergiotaborda]

[quote=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.[/quote]

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”

[sergiotaborda]

[quote=louds][quote=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
[/quote]

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

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)

Uma propertie não precisa suportar notificação, assim como um evento não precisa estar associado somente a propriedades.

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.

[quote]
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.[/quote]

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 ?

[pcalcado]

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:

JavaBeans Component Design Conventions

JavaBeans component design conventions govern the properties of the class and govern the public methods that give access to the properties.

A JavaBeans component property can be

* Read/write, read-only, or write-only
* Simple, which means it contains a single value, or indexed, which means it represents an array of values

A property does not have to be implemented by an instance variable. It must simply be accessible using public methods that conform to the following conventions:

* For each readable property, the bean must have a method of the form

    PropertyClass getProperty() { ... } 

* For each writable property, the bean must have a method of the form

    setProperty(PropertyClass pc) { ... } 

In addition to the property methods, a JavaBeans component must define a constructor that takes no parameters.

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

The Duke’s Bookstore application JSP pages bookstore.jsp, bookdetails.jsp, catalog.jsp, and showcart.jsp use the com.sun.bookstore2.database.BookDB and com.sun.bookstore2.database.BookDetails JavaBeans components. BookDB provides a JavaBeans component front end to the access object BookDBAO. The JSP pages showcart.jsp and cashier.jsp access the bean com.sun.bookstore.cart.ShoppingCart, which represents a user’s shopping cart.

The BookDB bean has two writable properties, bookId and database, and three readable properties: bookDetails, numberOfBooks, and books. These latter properties do not correspond to any instance variables but rather are a function of the bookId and database properties.

package database;
public class BookDB {
private String bookId = “0”;
private BookDBAO database = null;
public BookDB () {
}
public void setBookId(String bookId) {
this.bookId = bookId;
}
public void setDatabase(BookDBAO database) {
this.database = database;
}
public Book getBook() throws
BookNotFoundException {
return (Book)database.getBook(bookId);
}
public List getBooks() throws BooksNotFoundException {
return database.getBooks();
}
public void buyBooks(ShoppingCart cart)
throws OrderException {
database.buyBooks(cart);
}
public int getNumberOfBooks() throws BooksNotFoundException {
return database.getNumberOfBooks();
}
}

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ê:

Definition: What is a Bean?

If you use builder tools, such as Delphi or Visual Basic, you are already familiar with the notion of a bean. A JavaBean is a reusable software component that is written in Java programming language. It can be visually manipulated in builder tools. A JavaBean is often referred to simply as a Bean.

Software components are self-contained, reusable software units. Using visual application builder tools, software components can be composed into applets, applications, servlets, and composite components. You perform this composition within a graphical user interface, and you can immediately see the results of your work.

…
What Distinguishes JavaBeans from Widgets?

JavaBeans define a design-time interface. This interface allows application designer tools, or builder tools, to query components to determine the kinds of properties the components define and the kinds of events they generate or to which they respond.

In visual application builder environments, Beans are sometimes referred to as reusable software components or custom controls. Software components such as JavaBeans are packaged differently from standard Windows controls or Motif widgets. They are packaged with design-time information (properties and methods) that allow builder tools to determine their capabilities.

In addition, end users, or third party suppliers, can build custom beans independently of the GUI platform or operating system. IS departments can distribute these third-party components to internal enterprise clients, or they can be sold as add-on components to anyone who uses builder tools to construct applications.

What Distinguishes JavaBeans from Java Classes?

Any Java class that adheres to certain conventions regarding property and event interface definitions can be a JavaBean. Beans are Java classes that can be manipulated in a visual builder tool and composed into applications.

Introspection, the process by which a builder tool analyzes how a Bean works, differentiates Beans from typical Java classes. Because Beans are coded with predefined patterns for their method signatures and class definitions, tools that recognize these patterns can “look inside” a Bean and determine its properties and behavior.

Introspection allows a Bean’s state to be manipulated at design time?that is, at the time it is being assembled as a part within a larger application. For this to work, method signatures within Beans must follow a certain pattern so that introspection tools recognize how Beans can be manipulated, both at design time and at run time.

In effect, Beans publish their attributes and behaviors through special method signature patterns that are recognized by beans-aware application construction tools. However, these construction tools are not required to build or test your beans. The pattern signatures are easily recognized by human readers, as well as builder tools. One of the first things you’ll learn when building beans is how to recognize and construct methods that adhere to these patterns.

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

[jonataswingeter]

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…?!.

[sergiotaborda]

[quote=pcalcado]Ai ai ai…
[/quote]

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 ?