JavaBeans
Un JavaBean est une classe qui suit les conventions JavaBeans 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 création. En pratique, ce sont des classes écrites dans le langage de programmation Java conformément à une convention particulière. Ils sont utilisés pour encapsuler de nombreux objets en un seul objet (le bean), afin qu'ils puissent être transmis comme un seul objet bean au lieu de plusieurs objets individuels. Un JavaBean est un objet Java qui est sérialisable, possède un constructeur nullary et permet d'accéder aux propriétés à l'aide de méthodes getter et setter.
Pour fonctionner en tant que classe JavaBean, une classe d'objet doit obéir à certaines conventions concernant la dénomination, la construction et le comportement des méthodes. Ces conventions permettent d'avoir des outils qui peuvent utiliser, réutiliser, remplacer et connecter des JavaBeans.
Les conventions requises sont:
- La classe doit avoir un constructeur par défaut public. Cela permet une instanciation facile dans les cadres d'édition et d'activation.
- Les propriétés de classe doivent être accessibles à l'aide de get, set et d'autres méthodes (méthodes appelées accesseurs et méthodes de mutation), selon une convention de dénomination standard. Cela permet une inspection et une mise à jour automatisées faciles de l'état du bean dans les frameworks, dont beaucoup incluent des éditeurs personnalisés pour différents types de propriétés.
- La classe doit être sérialisable. Cela permet aux applications et aux infrastructures de sauvegarder, stocker et restaurer de manière fiable l'état du bean d'une manière indépendante de la machine virtuelle et de la plate-forme.
Étant donné que ces exigences sont largement exprimées sous forme de conventions plutôt que par l'implémentation d'interfaces, certains développeurs considèrent les JavaBeans comme des objets Java anciens simples qui suivent des conventions de dénomination spécifiques.
POJO
Un Plain Old Java Object ou POJO est un terme initialement introduit pour désigner un simple objet Java léger, ne mettant en œuvre aucune javax.ejb
interface, contrairement aux EJB 2.x lourds (en particulier les Entity Beans, les Stateless Session Beans ne sont pas si mauvais que ça). Aujourd'hui, le terme est utilisé pour tout objet simple sans élément supplémentaire. 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 sommes demandé 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 de fantaisie.
Le terme reprend le modèle des termes plus anciens pour les technologies qui n'utilisent pas de nouvelles fonctionnalités sophistiquées, telles que POTS (Plain Old Telephone Service) en téléphonie et PODS (Plain Old Data Structures) qui sont définis en C ++ mais utilisent uniquement des fonctionnalités en langage C, et POD (Plain Old Documentation) en Perl.
Le terme a très probablement gagné une large acceptation en raison de la nécessité d'un terme commun et facilement compréhensible qui contraste avec les cadres d'objets complexes. 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 classe unique mais un modèle de composant complet (encore une fois, EJB 3 réduit la complexité des Enterprise JavaBeans).
Comme les conceptions utilisant des POJO sont devenues plus couramment utilisées, des systèmes sont apparus qui donnent aux POJO une partie des fonctionnalités utilisées dans les frameworks et plus de choix sur les domaines de fonctionnalité réellement nécessaires. Hibernate et Spring en sont des exemples.
Objet de valeur
Un objet de valeur ou VO est un objet tel que java.lang.Integer
celui qui contient des valeurs (d'où des objets de valeur). Pour une définition plus formelle, je me réfère souvent à la description de Martin Fowler de l' objet de valeur :
Dans Patterns of Enterprise Application Architecture, j'ai décrit Value Object comme un petit objet tel qu'un objet Money ou Date Range. Leur propriété clé est qu'ils suivent la sémantique des valeurs plutôt que la sémantique de référence.
Vous pouvez généralement leur dire que leur notion d'égalité n'est pas basée sur l'identité, mais 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 heuristique générale est que les objets de valeur doivent être entièrement immuables. Si vous souhaitez modifier un objet de valeur, vous devez remplacer l'objet par un nouveau et ne pas être autorisé à mettre à jour les valeurs de l'objet de valeur lui-même - les objets de valeur pouvant être mis à jour entraînent des problèmes d'alias.
Les premières publications J2EE utilisaient le terme objet valeur pour décrire une notion différente, ce que j'appelle un objet de transfert de données . Depuis, ils ont changé leur utilisation et utilisent plutôt le terme objet de transfert .
Vous pouvez trouver plus de bons matériaux sur les objets de valeur sur le wiki et par Dirk Riehle .
Objet de transfert de données
L'objet de transfert de données ou DTO est un (anti) modèle 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 qui pouvait être transféré sur le réseau: un objet de transfert de données. Wikipedia a une définition décente de l' objet de transfert de données :
L'objet de transfert de données (DTO), anciennement appelé objets de valeur ou VO, est un modèle de conception utilisé pour transférer des données entre des sous-systèmes d'application logicielle. Les DTO sont souvent utilisés en conjonction avec des objets d'accès aux données pour récupérer les 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 aucun comportement, sauf pour le stockage et la récupération de ses propres données (accesseurs et mutateurs).
Dans une architecture EJB traditionnelle, les DTO ont un double objectif: premièrement, ils contournent le problème que les beans entité ne sont pas sérialisables; deuxièmement, ils définissent implicitement une phase d'assemblage où toutes les données à utiliser par la vue sont extraites et rassemblées dans les DTO avant de retourner le contrôle au niveau de présentation.
Donc, pour beaucoup de gens, 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 aussi des JavaBeans. Et tous sont des POJO.