Ont vu quelques questions similaires :
Pouvez-vous aussi me dire dans quels contextes ils sont utilisés ? Ou quel est leur objectif ?
Un JavaBean est une classe qui suit les conventions JavaBeans telles que définies par Sun. Wikipedia a un assez bon résumé de ce que sont les JavaBeans:
Les JavaBeans sont des composants logiciels réutilisables pour Java qui peuvent être manipulés visuellement dans un outil de construction. Pratiquement, ce sont des classes écrites dans le langage de programmation Java conformes à une convention particulière. Ils sont utilisés pour encapsuler de nombreux objets dans un seul objet (le bean), afin qu'ils puissent être transmis en tant qu'un seul objet bean au lieu de plusieurs objets individuels. Un JavaBean est un objet Java qui est sérialisable, possède un constructeur nullaire et permet d'accéder aux propriétés à l'aide de méthodes setter et getter.
Pour fonctionner en tant que classe JavaBean, une classe d'objet doit respecter certaines conventions en matière de nommage de méthodes, de construction et de comportement. Ces conventions permettent d'avoir des outils qui peuvent utiliser, réutiliser, remplacer et connecter les JavaBeans.
Les conventions requises sont les suivantes:
- La classe doit avoir un constructeur par défaut public. Cela permet une instantiation facile dans les cadres d'édition et d'activation.
- Les propriétés de la classe doivent être accessibles en utilisant des méthodes get, set, et d'autres méthodes (appelées méthodes d'accès et méthodes de mutation), en suivant une convention de nommage standard. Cela permet une inspection automatisée et une mise à jour facile de l'état du bean dans les frameworks, dont beaucoup incluent des éditeurs personnalisés pour divers types de propriétés.
- La classe doit être sérialisable. Cela permet aux applications et aux frameworks de sauvegarder, stocker et restaurer de manière fiable l'état du bean de manière indépendante de la VM et de la plate-forme.
Étant donné que ces exigences sont largement exprimées sous forme de conventions plutôt que par la mise en œuvre d'interfaces, certains développeurs considèrent les JavaBeans comme des Plain Old Java Objects qui suivent des conventions de nommage spécifiques.
Un Plain Old Java Object ou POJO est un terme initialement introduit pour désigner un simple objet Java léger, n'implémentant aucune interface javax.ejb, contrairement aux lourdes EJB 2.x (notamment les Entity Beans, les Stateless Session Beans ne sont pas si mauvais à mon avis). Aujourd'hui, le terme est utilisé pour tout objet simple sans éléments supplémentaires. Encore une fois, Wikipedia fait un bon travail pour définir POJO:
POJO est un acronyme pour Plain Old Java Object. Le nom est utilisé pour souligner que l'objet en question est un objet Java ordinaire, pas un objet spécial, et en particulier pas un Enterprise JavaBean (surtout avant EJB 3). Le terme a été inventé par Martin Fowler, Rebecca Parsons et Josh MacKenzie en septembre 2000 :
"Nous nous demandions pourquoi les gens étaient si contre l'utilisation d'objets réguliers dans leurs systèmes et nous avons conclu que c'était parce que les objets simples manquaient d'un nom fantaisiste. Nous leur en avons donné un, et cela a très bien pris."
Le terme poursuit le schéma des anciens termes pour les technologies qui n'utilisent pas de nouvelles fonctionnalités fantaisistes, comme POTS (Plain Old Telephone Service) en téléphonie, et PODS (Plain Old Data Structures) qui sont définis en C++ mais utilisent uniquement les fonctionnalités du langage C, et POD (Plain Old Documentation) en Perl.
Le terme a très probablement acquis une acceptation généralisée en raison du besoin d'un terme commun et facile à comprendre qui se distingue des cadres d'objets compliqués. Un JavaBean est un POJO qui est sérialisable, possède un constructeur sans argument et permet d'accéder aux propriétés à l'aide de méthodes getter et setter. Un Enterprise JavaBean n'est pas une seule classe mais un modèle de composant entier (encore une fois, EJB 3 réduit la complexité des Enterprise JavaBeans).
À mesure que les conceptions utilisant des POJOs sont devenues plus courantes, des systèmes sont apparus qui fournissent aux POJOs une partie des fonctionnalités utilisées dans les frameworks et offrent plus de choix sur les domaines de fonctionnalité réellement nécessaires. Hibernate et Spring en sont des exemples.
Un Value Object ou VO est un objet tel que java.lang.Integer qui stocke des valeurs (d'où les objets de valeur). Pour une définition plus formelle, je me réfère souvent à la description de Value Object de Martin Fowler sur Value Object:
Dans Patterns of Enterprise Application Architecture, j'ai décrit Value Object comme un petit objet tel qu'un objet Money ou une plage de dates. Leur propriété clé est qu'ils suivent les sémantiques de valeur plutôt que les sémantiques de référence.
Vous pouvez généralement les reconnaître car leur notion d'égalité n'est pas basée sur l'identité, deux objets de valeur sont égaux si tous leurs champs sont égaux. Bien que tous les champs soient égaux, vous n'avez pas besoin de comparer tous les champs si un sous-ensemble est unique - par exemple, les codes de devise pour les objets de devise suffisent pour tester l'égalité.
Une règle générale est que les objets de valeur doivent être entièrement immuables. Si vous souhaitez modifier un objet de valeur, vous devez le remplacer par un nouveau et non permettre de mettre à jour les valeurs de l'objet de valeur lui-même - les objets de valeur modifiables entraînent des problèmes d'aliasing.
Les premières publications J2EE utilisaient le terme value object pour décrire une notion différente, ce que j'appelle un Data Transfer Object. Ils ont depuis modifié leur utilisation et utilisent le terme Transfer Object à la place.
Vous pouvez trouver plus de bonnes ressources sur les objets de valeur sur le wiki et par Dirk Riehle.
Un Data Transfer Object ou DTO est un motif (anti) introduit avec EJB. Au lieu d'effectuer de nombreux appels distants sur des EJB, l'idée était d'encapsuler des données dans un objet de valeur pouvant être transféré sur le réseau : un Data Transfer Object. Wikipedia donne une définition décente de Data Transfer Object:
Le Data Transfer Object (DTO), anciennement connu sous le nom d'objets de valeur ou VO, est un motif de conception utilisé pour transférer des données entre les sous-systèmes d'une application logicielle. Les DTO sont souvent utilisés en conjonction avec des objets d'accès aux données pour récupérer des données d'une base de données.
La différence entre les objets de transfert de données et les objets métier ou les objets d'accès aux données est qu'un DTO n'a pas de comportement sauf pour le stockage et la récupération de ses propres données (accèsseurs et mutateurs).
Dans une architecture EJB traditionnelle, les DTO remplissent deux objectifs : d'une part, ils contournent le problème selon lequel les beans entité ne sont pas sérialisables ; d'autre part, ils définissent implicitement une phase d'assemblage où toutes les données à utiliser par la vue sont récupérées et assemblées dans les DTO avant de renvoyer le contrôle à la couche de présentation.
Ainsi, pour de nombreuses personnes, les DTO et les VO sont la même chose (mais Fowler utilise les VO pour signifier autre chose comme nous l'avons vu). La plupart du temps, ils suivent les conventions JavaBeans et sont donc également des JavaBeans. Et tous sont des POJOs.
Donc, si j'ai une classe de commodité créée uniquement pour transférer des données non liées comme celle-ci class SomeClass { public String foo; public String bar; } à l'intérieur d'une classe avec beaucoup de logique compliquée, ce n'est certainement pas un JavaBean, cela ne peut pas être un VO car il est mutable, pourrait-il être un DTO? bien qu'il ne soit pas destiné aux invocations distantes d'aucune sorte. Peut-il être considéré comme un POJO?
Désolé pour le commentaire tellement en retard, mais j'apprends les différences entre eux et j'ai une question. Que se passerait-il si j'avais une classe Java Bean, mais avec d'autres méthodes comme doSomething(). Quel type de classe serait-ce ? Cordialement
@user2601512: Ce serait toujours une Bean. :P Il n'y a rien de mal à ce qu'une Bean ait un comportement - en fait, c'est pratiquement attendu. Si elle ne fait rien d'autre, c'est essentiellement un DTO.
DTO vs VO
DTO - Les objets de transfert de données ne sont que des conteneurs de données utilisés pour transporter des données entre les couches et les tiers.
Analogie:
Formulaire d'inscription simple avec des attributs nom d'utilisateur, mot de passe et adresse e-mail.
- Lorsque ce formulaire est soumis dans le fichier RegistrationServlet, vous obtiendrez tous les attributs de la couche de vue à la couche métier où vous passez les attributs aux beans Java, puis au DAO ou à la couche de persistance.
- Les DTO aident à transporter les attributs de la couche de vue à la couche métier et enfin à la couche de persistance.
Les DTO étaient principalement utilisés pour transporter des données efficacement à travers le réseau, même d'un JVM à un autre.
Les DTO sont souvent java.io.Serializable - pour transférer des données entre les JVM.
VO - Un Value Object [1][2] représente un ensemble fixe de données et est similaire à une énumération Java. L'identité d'un Value Object est basée sur son état plutôt que sur son identité d'objet et il est immuable. Un exemple concret serait Color.RED, Color.BLUE, SEX.FEMALE etc.
POJO vs JavaBeans
[1] La natura Java-Bean d'un POJO est que ses attributs privés sont tous accessibles via des getters et setters publics conformes aux conventions JavaBeans. par exemple.
private String foo;
public String getFoo(){...}
public void setFoo(String foo){...}; [2] Les JavaBeans doivent implémenter Serializable et avoir un constructeur sans argument, alors qu'un POJO n'a pas ces restrictions.
Désolé pour le retard du commentaire, mais je suis en train d'apprendre les différences entre eux et j'ai une question. Et si j'ai une classe Java Bean, mais avec d'autres méthodes comme doSomething(). Quel type de classe serait-ce? Cordialement
Essentiellement,
DTO : "Objets de transfert de données" peuvent voyager entre des couches séparées dans l'architecture logicielle.
VO : "Objets de valeur" contiennent un objet tel qu'un entier, de l'argent, etc.
POJO : Plain Old Java Object qui n'est pas un objet spécial.
Java Beans : nécessite une classe Java pour être sérialisée, avoir un constructeur no-arg et un getter et setter pour chaque champ.
Les Java Beans ne sont pas la même chose que les EJBs.
La spécification JavaBeans en Java 1.0 était la tentative de Sun pour permettre aux objets Java d'être manipulés dans un IDE qui ressemblait à VB. Il y avait des règles établies pour les objets qualifiés de "Java Beans" :
Les EJBs sont venus plus tard. Ils combinent des composants distribués et un modèle transactionnel, s'exécutant dans un conteneur qui gère les threads, le pooling, le cycle de vie et fournit des services. Ils sont très différents des Java Beans.
Les DTOs ont vu le jour dans le contexte de Java car les gens ont découvert que la spécification EJB 1.0 était trop bavarde avec la base de données. Au lieu de faire un aller-retour pour chaque élément de données, les gens les empaquetaient en Java Beans en vrac et les envoyaient.
Les POJOs étaient une réaction contre les EJBs.
J'avais tort et j'ai préféré supprimer mon message. Merci pour la correction. Je tiens à signaler que le sens de POJO a changé il y a quelque temps. D'abord, ils étaient uniquement composés de propriétés privées et de leurs accesseurs. Maintenant, nous considérons un POJO comme une classe avec des annotations, implémentant et étendant d'autres classes, etc.
Quand il s'agit de récupérer des données à partir du référentiel, vous utilisez DTO quand il s'agit de transférer des valeurs entre les couches, vous utilisez VO quand il s'agit d'objet utilisé sans besoin de conteneur spécifique, vous utilisez POJO quand il s'agit des conventions JavaBeans mentionnées ci-dessus, vous utilisez JavaBeans
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
POJO vient sans restriction alors que javabeans vient avec les restrictions mentionnées ci-dessus