web-dev-qa-db-fra.com

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

J'ai vu des questions similaires:

Pouvez-vous également me dire dans quels contextes ils sont utilisés? Ou le but d'eux?

javaterminologyjavabeansdtopojo
526
jai

JavaBeans

Un JavaBean est une classe qui suit les conventions JavaBeans telles que définies par Sun. Wikipedia a un très bon résumé de ce que JavaBeans sont:

Les JavaBeans sont des composants logiciels réutilisables pour Java pouvant être manipulés visuellement dans un outil de construction. Pratiquement, ce sont des classes écrites dans le langage de programmation Java conforme à une convention particulière. Ils sont utilisés pour encapsuler de nombreux objets dans un seul objet (le bean), de sorte qu'ils puissent être transmis comme un seul objet de bean au lieu de plusieurs objets individuels. Un JavaBean est un objet Java sérialisable, doté d'un constructeur nullary et permettant l'accès 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 relatives à la dénomination, à la construction et au comportement des méthodes. Ces conventions permettent de disposer d'outils capables d'utiliser, de réutiliser, de remplacer et de 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 la classe doivent être accessibles à l'aide de get, set et d'autres méthodes (appelées méthodes d'accès et méthodes de mutation), conformément à une convention d'appellation standard. Cela permet une inspection et une mise à jour automatisées et faciles de l'état des beans dans des frameworks, dont beaucoup incluent des éditeurs personnalisés pour différents types de propriétés.
  • La classe devrait être sérialisable. Cela permet aux applications et aux infrastructures d'enregistrer, de stocker et de restaurer de manière fiable l'état du bean de manière indépendante de la plate-forme VM.

É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 de simples anciens Java Objets qui respectent des conventions de dénomination spécifiques.

POJO

Un ancien objet Java ou POJO est un terme initialement introduit pour désigner un objet Java léger et simple, qui ne met en oeuvre aucune interface javax.ejb, par opposition à EJB 2.x de poids lourd (En particulier les beans Entity, les beans session sans état ne sont pas si mauvais OMI). Aujourd'hui, le terme est utilisé pour tout objet simple, sans matériel supplémentaire. Encore une fois, Wikipedia fait un bon travail en définissant 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, et non un objet spécial, et en particulier un Enterprise JavaBean (en particulier 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 opposés à utiliser des objets normaux dans leur système et nous avons conclu que c'était parce que les objets simples n'avaient pas un nom sophistiqué. Nous leur en avons donc donné un et ils ont été très bien compris."

Le terme poursuit le modèle des termes plus anciens pour les technologies qui n'utilisent pas de nouvelles fonctionnalités sophistiquées, telles que POTS (service téléphonique normal ancien) en téléphonie et les PODS (structures anciennes de données simples) définies en C++ mais n'utilisant que les fonctionnalités du langage C, et POD (Plain Old Documentation) en Perl.

Le terme a probablement été largement accepté, en raison de la nécessité d'un terme commun facile à comprendre, qui contraste avec les cadres d'objet complexes. Un JavaBean est un POJO sérialisable, doté d'un constructeur sans argument et permettant l'accès 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é d'Enterprise JavaBeans).

Alors que les conceptions utilisant des POJO sont de plus en plus utilisées, des systèmes ont été créés qui donnent aux POJO certaines des fonctionnalités utilisées dans les frameworks et un plus grand choix quant aux 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 qui contient des valeurs (donc des objets de valeur). Pour une définition plus formelle, je me réfère souvent à la description de Martin Fowler de 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 une plage de dates. Leur propriété clé est qu'ils suivent la sémantique de valeur 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 que deux objets de valeur sont égaux si tous leurs champs sont égaux. Bien que tous les champs soient égaux, il n'est pas nécessaire de comparer tous les champs si un sous-ensemble est unique - par exemple, les codes de devise pour les objets de devise suffisent à tester l'égalité.

Une heuristique générale veut que les objets de valeur soient entièrement immuables. Si vous souhaitez modifier un objet de valeur, vous devez remplacer cet objet par un nouvel objet 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 de valeur pour décrire une notion différente, que j'appelle un objet de transfert de données . Depuis, ils ont modifié leur utilisation et utilisent à la place le terme objet de transfert .

Vous pouvez trouver encore de la bonne matière 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 modèle (anti) introduit avec EJB. Au lieu d'effectuer de nombreux appels à distance sur des EJB, il s'agissait d'encapsuler des données dans un objet de valeur pouvant être transféré sur le réseau: un objet de transfert de données. Wikipedia a une définition correcte de objet de transfert de données :

L'objet de transfert de données (DTO), anciennement appelé objet 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 avec des objets d'accès aux données pour extraire 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 aucun comportement, à l'exception du stockage et de la récupération de ses propres données (accesseurs et mutateurs).

Dans une architecture EJB traditionnelle, les DTO remplissent deux fonctions: premièrement, ils résolvent le problème que les beans entité ne sont pas sérialisables; Deuxièmement, ils définissent implicitement une phase d'assemblage dans laquelle toutes les données à utiliser par la vue sont extraites et placées dans les DTO avant de rendre le contrôle au niveau 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 que ce que nous avons vu). La plupart du temps, ils suivent les conventions JavaBeans et sont donc également JavaBeans. Et tous sont des POJO.

792
Pascal Thivent

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 couches et niveaux.

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

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

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

Le DTO était principalement utilisé pour transférer efficacement les données sur le réseau. Il peut même s'agir d'une machine virtuelle vers une autre machine virtuelle.

Les DTO sont souvent Java.io.Serializable - afin de transférer des données via JVM.

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

POJO vs JavaBeans

[1] Le Java-Beanness d'un POJO réside dans le fait que tous ses attributs privés sont accessibles via des sélecteurs et des régleurs 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 dans POJO, ces restrictions ne sont pas appliquées.

60
Srinivas M.V.

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 Objet qui n'est pas un objet spécial.

Java Beans: nécessite qu'un Java Class soit sérialisable, possède un constructeur no-arg, ainsi qu'un getter et un setter pour chaque champ

42
Olcay Tarazan

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 d'autoriser les objets Java à être manipulés dans un IDE ressemblant à VB. Des règles ont été 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 arrivés 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 loin des Java Beans.

Les DTO sont apparus dans le contexte Java, car les utilisateurs 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 utilisateurs les empaquetaient dans Java Beans en bloc et les expédiaient.

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

24
duffymo

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

Bean: Il s'agit d'un fichier (classe) Java dans lequel toutes les variables sont privées, les méthodes sont publiques et des 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 fichier (classe).

4
Suraj Kalokhe

Premier entretien sur

Classe normale- Cela signifie que toute classe définit comme étant normalement dans Java. Cela signifie que vous créez un type différent de propriétés de méthode etc. =
Bean - Bean n’est rien, c’est seulement un objet de cette classe particulière qui utilise ce bean. Vous pouvez accéder à votre classe Java de la même manière qu’un objet ..

et après que parler de la dernière POJO

POJO - POJO est cette classe qui n'a aucun service, elle n'a qu'un constructeur par défaut, une propriété privée et ces propriétés permettant de définir une valeur correspondant aux méthodes setter et getter . C'est la forme abrégée de Plain Java Object.

1
ASHISH KUMAR SINGH
  • Value Object : à utiliser lorsque nécessaire pour mesurer l'égalité des objets en fonction de la valeur de ces derniers.
  • Objet de transfert de données : transférez des données avec plusieurs attributs en une seule fois, d'un client à un autre, sur plusieurs couches, pour éviter les appels multiples au serveur distant.
  • Plain Old Java Object : il ressemble à une simple classe dont les propriétés sont un constructeur public sans argument. Comme nous le déclarons pour l'entité JPA.

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

0
Atul Jain