Différence entre DTO, VO, POJO, JavaBeans?

J'ai vu des questions similaires:

• Quelle est la différence entre un JavaBean et un POJO?
• Quelle est la différence entre POJO (Plain Old Java Object) et DTO (Data Transfer Object)?

Pouvez-vous également me dire dans quels contextes ils sont utilisés? Ou leur objectif?

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.ejbinterface, 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.Integercelui 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.

DTO vs VO

DTO - Les objets de transfert de données ne sont que des conteneurs de données qui sont utilisés pour transporter des données entre des couches et des niveaux.

• Il contient principalement des attributs. Vous pouvez même utiliser des attributs publics sans getters ni setters.
• Les objets de transfert de données ne contiennent aucune logique métier.

Analogie:
formulaire d'inscription simple avec attributs nom d'utilisateur, mot de passe et identifiant de messagerie.

• Lorsque ce formulaire est soumis dans le fichier RegistrationServlet, vous obtiendrez tous les attributs de la couche d'affichage à la couche métier où vous transmettez les attributs aux beans Java, puis au DAO ou à la couche de persistance.
• Le DTO aide à transporter les attributs de la couche de vue à la couche métier et enfin à la couche de persistance.

Le DTO était principalement utilisé pour faire transporter efficacement les données à travers le réseau, il peut même être de JVM à une autre JVM.

Les DTO sont souvent java.io.Serializable- afin de transférer des données à travers JVM.

VO - Un objet de valeur [1] [2] représente lui-même un ensemble fixe de données et est similaire à une énumération Java. L'identité d'un objet de valeur est basée sur son état plutôt que sur son identité d'objet et est immuable. Un exemple réel serait Color.RED, Color.BLUE, SEX.FEMALE etc.

POJO vs JavaBeans

[1] Le Java-Beanness 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] JavaBeans doit implémenter Serializable et avoir un constructeur sans argument, alors que POJO n'a pas ces restrictions.

Fondamentalement,

DTO: les «objets de transfert de données» peuvent voyager entre des couches distinctes dans l'architecture logicielle.

VO: "Les objets de valeur" contiennent un objet tel que Integer, Money, etc.

POJO: Plain Old Java Object qui n'est pas un objet spécial.

Java Beans: nécessite un Java Classpour être sérialisable, avoir un no-argconstructeur et un getter et setter pour chaque champ

Les Java Beans ne sont pas la même chose que les EJB.

La spécification JavaBeans dans Java 1.0 était la tentative de Sun de permettre aux objets Java d'être manipulés dans un IDE qui ressemblait à VB. Des règles étaient définies pour les objets qualifiés de "Java Beans":

1. Constructeur par défaut
2. Getters et setters pour les membres de données privées qui ont suivi la convention de nommage appropriée
3. Sérialisable
4. Peut-être d'autres que j'oublie.

Les EJB 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, la mise en commun, le cycle de vie et fournit des services. Ils sont loin de Java Beans.

Les DTO sont apparus dans le contexte Java parce que les gens ont découvert que la spécification EJB 1.0 était trop "bavarde" avec la base de données. Plutôt que de faire un aller-retour pour chaque élément de données, les gens les regrouperaient en Java Beans en vrac et les expédieraient.

Les POJO étaient une réaction contre les EJB.

POJO : Il s'agit d'un fichier java (classe) qui n'étend ni n'implémente aucun autre fichier java (classe).

Bean : C'est un fichier java (classe) dans lequel toutes les variables sont privées, les méthodes sont publiques et les getters et setters appropriés sont utilisés pour accéder aux variables.

Classe normale : il s'agit d'un fichier java (classe) qui peut être constitué de variables publiques / privées / par défaut / protégées et qui peut ou non étendre ou implémenter un autre fichier java (classe).

Tout d'abord parler

Normale classe - que de dire toute la classe définissent c'est un normalement en Java signifie que c'est des vous créez différents types de propriétés de la méthode , etc.
Bean - Bean est rien c'est seulement un objet de cette classe particulière en utilisant ce haricot , vous pouvez accéder à votre classe java même comme objet. .

et après cela, parler du dernier POJO

POJO - POJO est cette classe qui n'a aucun service, elle n'a qu'un constructeur par défaut et une propriété privée et ces propriétés pour définir une valeur correspondant aux méthodes setter et getter. C'est une forme courte d'objet Java simple.

• Objet de valeur : à utiliser lorsque vous avez besoin de mesurer l'égalité des objets en fonction de la valeur des objets.
• Objet de transfert de données : passez des données avec plusieurs attributs en une seule fois du client au serveur à travers la couche, pour éviter plusieurs appels vers le serveur distant.
• Plain Old Java Object : C'est comme une classe simple dont les propriétés, un constructeur public sans arg. Comme nous le déclarons pour l'entité JPA.

différence-entre-valeur-modèle-d'objet-et-modèle-de-transfert-de-données