Quelle est la différence entre un JavaBean et un POJO?

Je ne suis pas sûr de la différence. J'utilise Hibernate et, dans certains livres, ils utilisent JavaBean et POJO comme terme interchangeable. Je veux savoir s'il y a une différence, pas seulement dans le contexte d'Hibernate, mais en tant que concepts généraux.

Un JavaBean suit certaines conventions. Nommer un getter / setter, avoir un constructeur public par défaut, être sérialisable, etc. Voir Conventions JavaBeans pour plus de détails.

Un POJO (plain-old-Java-object) n'est pas rigoureusement défini. C'est un objet Java qui n'a pas besoin d'implémenter une interface particulière ou de dériver d'une classe de base particulière, ou d'utiliser des annotations particulières afin d'être compatible avec un cadre donné, et peut être arbitraire (souvent relativement simple) Objet Java.

Tous les JavaBeans sont des POJO mais tous les POJO ne sont pas des JavaBeans.

Un JavaBean est un objet Java qui satisfait certaines conventions de programmation:

• la classe JavaBean doit implémenter Serializable ou Externalizable;
• la classe JavaBean doit avoir un constructeur public sans argument;
• toutes les propriétés JavaBean doivent avoir des méthodes publiques setter et getter (le cas échéant);
• toutes les variables d'instance JavaBean doivent être privées.

Selon Martin Fowler, un POJO est un objet qui encapsule la logique métier tandis qu'un bean (à l'exception de la définition déjà indiquée dans d'autres réponses) n'est guère plus qu'un conteneur pour conserver des données et les opérations disponibles sur l'objet se contentent de définir et d'obtenir des données.

Le terme a été inventé alors que Rebecca Parsons, Josh MacKenzie et moi nous préparions pour une conférence lors d'une conférence en septembre 2000. Dans la conférence, nous soulignions les nombreux avantages de l'encodage de la logique métier dans des objets java ordinaires plutôt que d'utiliser Entity Beans. Nous nous sommes demandés pourquoi les gens étaient si contre l'utilisation d'objets ordinaires dans leurs systèmes et avons conclu que c'était parce que les objets simples n'avaient pas de nom fantaisiste. Nous leur en avons donc donné un, et il a très bien fonctionné.

http://www.martinfowler.com/bliki/POJO.html

POJO: Si la classe peut être exécutée avec le JDK sous-jacent, sans aucune autre bibliothèque tierce externe, alors elle s'appelle POJO

JavaBean: si la classe ne contient que des attributs avec des accesseurs (setters et getters), ceux-ci sont appelés javabeans.Les beans Java ne contiennent généralement pas de logique commerciale plutôt que ceux utilisés pour contenir certaines données.

Tous les Javabéens sont des POJO mais tous les POJO ne sont pas des Javabéens

Pojo - Objet java ancien uni

La classe pojo est une classe ordinaire sans aucune spécialité, la classe est totalement reliée à la technologie / au cadre. La classe n'implémente pas la technologie / le cadre et ne s'étend pas de la technologie / du cadre api cette classe est appelée classe pojo.

La classe pojo peut implémenter des interfaces et étendre des classes mais la super classe ou l'interface ne doit pas être une technologie / un framework.

Exemples :

1.

class ABC{
----
}

La classe ABC ne met pas en œuvre ou ne s'étend pas à partir de la technologie / du cadre, c'est pourquoi il s'agit de la classe pojo.

2.

class ABC extends HttpServlet{
---
}

Classe ABC s'étendant de l'API de la technologie des servlets, c'est pourquoi ce n'est pas une classe pojo.

3.

class ABC implements java.rmi.Remote{
----
}

La classe ABC implémente depuis rmi api c'est pourquoi ce n'est pas une classe pojo.

4.

class ABC implements java.io.Serializable{
---
}

cette interface fait partie du langage java ne fait pas partie de la technologie / framework.so c'est la classe pojo.

5.

class ABC extends Thread{
--
}

ici, le thread est également une classe de langage java, il s'agit donc également d'une classe pojo.

6.

class ABC extends Test{
--
}

si la classe Test s'étend ou implémente à partir de technologies / framework, ABC n'est pas non plus une classe pojo car elle hérite des propriétés de la classe Test. si la classe Test n'est pas une classe pojo, alors la classe ABC n'est pas non plus une classe pojo.

7.

maintenant ce point est un cas exceptionnel

@Entity
class ABC{
--
}

@Entityest une annotation donnée par hibernate api ou jpa api mais nous pouvons toujours appeler cette classe comme classe pojo. La classe avec des annotations provenant de la technologie / du framework est appelée classe pojo par ce cas exceptionnel.

Les beans Java sont un type spécial de POJO.

Spécialités énumérées ci-dessous avec raison

POJOSavec certaines conventions (getter / setter, constructeur public sans argument, variables privées) et sont en action (par exemple être utilisé pour lire des données par formulaire) JAVABEANS.

En résumé, les similitudes et les différences sont:

   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.

Tous les haricots JAVA sont des POJO mais tous les POJO ne sont pas des haricots JAVA.

Vous avez vu les définitions formelles ci-dessus, pour tout ce qu'elles valent.

Mais ne vous attardez pas trop sur les définitions. Regardons simplement le sens des choses ici.

Les JavaBeans sont utilisés dans les applications Java d'entreprise, où les utilisateurs accèdent fréquemment à distance aux données et / ou au code d'application, c'est-à-dire à partir d'un serveur (via le Web ou un réseau privé) via un réseau. Les données impliquées doivent donc être diffusées au format série dans ou hors des ordinateurs des utilisateurs - d'où le besoin d'objets Java EE pour implémenter l'interface Sérialisable. La majeure partie de la nature d'un JavaBean n'est pas différente des objets d'application Java SE dont les données sont lues dans ou écrites dans un système de fichiers. L'utilisation fiable des classes Java sur un réseau à partir d'une gamme de combinaisons utilisateur machine / système d'exploitation nécessite également l'adoption de conventions pour leur gestion. D'où la nécessité d'implémenter ces classes en public, avec des attributs privés, un constructeur sans argument et des getters et setters standardisés.

Les applications Java EE utiliseront également des classes autres que celles qui ont été implémentées en tant que JavaBeans. Ceux-ci peuvent être utilisés pour traiter les données d'entrée ou organiser les données de sortie, mais ne seront pas utilisés pour les objets transférés sur un réseau. Par conséquent, les considérations ci-dessus ne doivent pas être appliquées à la barre qui est valide en tant qu'objets Java. Ces dernières classes sont appelées POJO - Plain Old Java Objects.

Dans l'ensemble, vous pouvez voir les Java Beans comme de simples objets Java adaptés à une utilisation sur un réseau.

Il y a énormément de battage médiatique - et pas une petite quantité de conneries - dans le monde du logiciel depuis 1995.