Não tenho certeza da diferença. Estou usando o Hibernate e, em alguns livros, eles usam JavaBean e POJO como um termo intercambiável. Quero saber se há uma diferença, não apenas no contexto do Hibernate, mas como conceitos gerais.
Não tenho certeza da diferença. Estou usando o Hibernate e, em alguns livros, eles usam JavaBean e POJO como um termo intercambiável. Quero saber se há uma diferença, não apenas no contexto do Hibernate, mas como conceitos gerais.
Respostas:
Um JavaBean segue certas convenções. Nomeação de getter / setter, ter um construtor público padrão, ser serializável etc. Consulte Convenções do JavaBeans para obter mais detalhes.
Um POJO (objeto Java simples e antigo) não é rigorosamente definido. É um objeto Java que não precisa implementar uma interface específica ou derivar de uma classe base específica, ou fazer uso de anotações específicas para ser compatível com uma determinada estrutura e pode ser arbitrário (geralmente relativamente simples) Objeto Java.
Todos os JavaBeans são POJOs, mas nem todos os POJOs são JavaBeans.
Um JavaBean é um objeto Java que satisfaz certas convenções de programação:
Serializable
.
De acordo com Martin Fowler, um POJO é um objeto que encapsula a lógica de negócios, enquanto um Bean (exceto a definição já mencionada em outras respostas) é pouco mais que um contêiner para armazenar dados e as operações disponíveis no objeto apenas configuram e obtêm dados.
O termo foi cunhado enquanto Rebecca Parsons, Josh MacKenzie e eu estávamos nos preparando para uma palestra em uma conferência em setembro de 2000. Na palestra, destacamos os muitos benefícios de codificar a lógica de negócios em objetos Java regulares, em vez de usar o Entity Beans. Nós nos perguntamos por que as pessoas eram tão contra o uso de objetos regulares em seus sistemas e concluímos que era porque objetos simples não tinham um nome sofisticado. Por isso, demos a eles um, e ele pegou muito bem.
POJO: Se a classe puder ser executada com o JDK subjacente, sem nenhuma outra biblioteca externa de suporte, será chamado POJO
JavaBean: se a classe contiver apenas atributos com acessadores (setters e getters), eles serão chamados javabeans.Java beans geralmente não conterão nenhuma lógica de negócios, mas serão usados para armazenar alguns dados.
Todos os Javabeans são POJOs, mas todos os POJO não são Javabeans
Pojo - Objeto java antigo simples
A classe pojo é uma classe comum sem especialidades, classe totalmente acoplada à tecnologia / estrutura. a classe não implementa a partir da tecnologia / estrutura e não se estende da API de tecnologia / estrutura que a classe é chamada classe pojo.
A classe pojo pode implementar interfaces e estender classes, mas a superclasse ou interface não deve ser uma tecnologia / estrutura.
Exemplos :
1
class ABC{
----
}
A classe ABC não implementa ou se estende da tecnologia / estrutura, por isso é a classe pojo.
2)
class ABC extends HttpServlet{
---
}
A classe ABC se estende da API de servlet e é por isso que não é uma classe pojo.
3)
class ABC implements java.rmi.Remote{
----
}
A classe ABC implementa da rmi api e é por isso que essa não é uma classe pojo.
4)
class ABC implements java.io.Serializable{
---
}
essa interface faz parte da linguagem java e não da technology / framework.so é a classe pojo.
5)
class ABC extends Thread{
--
}
aqui o thread também é classe da linguagem java, então essa também é uma classe pojo.
6
class ABC extends Test{
--
}
se a classe Test se estende ou implementa a partir de tecnologias / estrutura, o ABC também não é uma classe pojo porque herda as propriedades da classe Test. se a classe Test não for uma classe pojo, a classe ABC também não será uma classe pojo.
7)
agora este ponto é um caso excepcional
@Entity
class ABC{
--
}
@Entity
é uma anotação dada por hibernate api ou jpa api, mas ainda podemos chamar essa classe como classe pojo. A classe com anotações fornecidas pela tecnologia / estrutura é chamada de classe pojo nesse caso excepcional.
POJOS
com certas convenções (getter / setter, construtor público no-arg, variáveis privadas) e estão em ação (por exemplo, sendo usadas para ler dados por formulário) JAVABEANS
.
Em resumo: semelhanças e diferenças são:
java beans: Pojo:
-must extends serializable -no need to extends or implement.
or externalizable.
-must have public class . - must have public class
-must have private instance variables. -can have any access specifier variables.
-must have public setter and getter method. - may or may not have setter or getter method.
-must have no-arg constructor. - can have constructor with agruments.
Todos os beans JAVA são POJO, mas nem todos os POJOs são JAVA Beans.
Você já viu as definições formais acima, por tudo que valem a pena.
Mas não se preocupe demais com as definições. Vamos apenas olhar mais para o sentido das coisas aqui.
O JavaBeans é usado em aplicativos Enterprise Java, onde os usuários freqüentemente acessam dados e / ou código do aplicativo remotamente, ou seja, de um servidor (via web ou rede privada) via rede. Os dados envolvidos devem, portanto, ser transmitidos em formato serial para dentro ou fora dos computadores dos usuários - daí a necessidade de objetos Java EE para implementar a interface Serializable. Essa natureza da JavaBean não é diferente dos objetos de aplicativos Java SE cujos dados são lidos ou gravados em um sistema de arquivos. O uso de classes Java de maneira confiável em uma rede a partir de uma variedade de combinações de máquina / sistema operacional do usuário também exige a adoção de convenções para seu manuseio. Daí o requisito para implementar essas classes como públicas, com atributos privados, um construtor sem argumentos e getters e setters padronizados.
Os aplicativos Java EE também usarão outras classes além daquelas que foram implementadas como JavaBeans. Elas podem ser usadas no processamento de dados de entrada ou na organização de dados de saída, mas não serão usadas para objetos transferidos pela rede. Portanto, as considerações acima não precisam ser aplicadas a elas, para que sejam válidas como objetos Java. Essas últimas classes são conhecidas como POJOs - Plain Old Java Objects.
Em suma, era possível ver o Java Beans apenas como objetos Java adaptados para uso em uma rede.
Há uma enorme quantidade de hype - e pouca quantidade de humbug - no mundo do software desde 1995.