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


Ont vu des questions similaires:

Pouvez-vous également me dire dans quel contexte ils sont utilisés? Ou leur but?


432
2017-10-23 09:30


origine


Réponses:


JavaBeans

Un JavaBean est une classe qui suit les conventions JavaBeans comme défini par Sun. Wikipedia a un assez bon résumé de ce que JavaBeans sont:

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 conforme à une convention particulière. Ils sont utilisés pour encapsuler de nombreux objets dans un seul objet (le bean), de manière à pouvoir les faire circuler sous la forme d'un objet bean unique au lieu de plusieurs objets individuels. Un JavaBean est un objet Java sérialisable, doté d'un constructeur nullaire et permettant d'accéder aux propriétés à l'aide des méthodes getter et setter.

Pour fonctionner en tant que classe JavaBean, une classe d'objets doit obéir à certaines conventions sur le nommage, la construction et le comportement des méthodes. Ces conventions permettent d'avoir des outils qui peuvent utiliser, réutiliser, remplacer et connecter JavaBeans.

Les conventions requises sont:

  • La classe doit avoir un constructeur public par défaut. Ceci permet une instanciation facile dans les cadres d'édition et d'activation.
  • Les propriétés de la classe doivent être accessibles à l'aide des méthodes get, set et autres (méthodes dites d'accesseur et méthodes de mutateur), selon une convention de dénomination standard. Cela permet une inspection et une mise à jour automatiques 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 devrait être sérialisable. Cela permet aux applications et aux frameworks d’enregistrer, de stocker et de restaurer l’état du bean de manière fiable, indépendamment de la machine virtuelle et de la plate-forme.

Étant donné que ces exigences sont en grande partie exprimées sous forme de conventions plutôt que par implémentation d'interfaces, certains développeurs considèrent les JavaBeans comme des objets Java classiques simples qui respectent des conventions de dénomination spécifiques.

POJO

Un Plain Old Java Object ou POJO est un terme initialement introduit pour désigner un objet Java léger et simple, ne mettant en œuvre aucun javax.ejb interface, par opposition à poids lourd EJB 2.x (en particulier Entity Beans, Stateless Session Beans ne sont pas si mal IMO). Aujourd'hui, le terme est utilisé pour n'importe quel objet simple sans trucs supplémentaires. Encore une fois, Wikipedia fait un bon travail à définir POJO:

POJO est un acronyme pour Plain Old Java   Objet. Le nom est utilisé pour souligner   que l'objet en question est un   objet Java ordinaire, pas un spécial   objet, 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és pourquoi les gens étaient si opposés à utiliser des objets réguliers dans leur     systèmes et a conclu qu'il était     parce que les objets simples manquaient de fantaisie     prénom. Nous leur avons donc donné un, et c'est     attrapé très bien. "

Le terme continue le schéma de   anciens termes pour les technologies qui font   ne pas utiliser de nouvelles fonctionnalités, telles que   POTS (Plain Old Telephone Service) dans   téléphonie et PODS (Plain Old Data)   Structures) définis en C ++   mais utilisez uniquement les fonctionnalités du langage C, et   POD (Plain Old Documentation) en Perl.

Le terme a très probablement gagné   acceptation généralisée en raison de la   besoin d'un commun et facilement   terme compris qui contraste avec   cadres d'objet compliqués. UNE   JavaBean est un POJO qui est   sérialisable, a un non-argument   constructeur, et permet l'accès à   propriétés utilisant getter et setter   méthodes Un Enterprise JavaBean n'est pas   une seule classe mais un composant entier   modèle (encore une fois, EJB 3 réduit la   complexité des Enterprise JavaBeans).

Comme les conceptions utilisant des POJO sont devenues   plus communément utilisés, les systèmes ont   surgi que donner aux POJO une partie de la   fonctionnalité utilisée dans les cadres et   plus de choix sur les domaines de   la fonctionnalité est en fait nécessaire.   Hibernate et Spring sont des exemples.

Objet de valeur

Un objet de valeur ou VO est un objet tel que java.lang.Integer qui contiennent 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 principale propriété est de suivre la sémantique des valeurs plutôt que la sémantique de référence.

Vous pouvez généralement leur dire parce que leur notion d'égalité n'est pas basée sur l'identité, à la place deux objets 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 sont suffisants pour tester l'égalité.

Une heuristique générale est que les objets de valeur doivent être entièrement immuables. Si vous voulez changer 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 valeurs modifiables conduisent à des problèmes d'alias.

La littérature de J2EE tôt a employé le terme objet de valeur pour décrire une notion différente, ce que j'appelle un Objet de transfert de données. Ils ont depuis changé leur usage et utilisent le terme Objet de transfert au lieu.

Vous pouvez trouver du matériel plus 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 à distance 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 objet de transfert de données. Wikipedia a une définition décente de Objet de transfert de données:

L'objet de transfert de données (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 des sous-systèmes d'application logicielle. Les objets DTO sont souvent utilisés conjointement 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 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 selon lequel 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 récupérées et regroupées dans les DTO avant de renvoyer le contrôle au niveau de présentation.


Ainsi, pour beaucoup de gens, les DTO et les VO sont la même chose (mais Fowler utilise les VO pour signifier autre chose que nous avons vu). La plupart du temps, ils suivent les conventions JavaBeans et sont donc aussi JavaBeans. Et tous sont des POJO.


697
2017-10-23 10:51



DTO vs VO

DTO - Les objets de transfert de données sont simplement 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 et setters.
  • Les objets de transfert de données ne contiennent aucune logique métier.

Analogie: 
Formulaire d'inscription simple avec nom d'utilisateur des attributs,   mot de passe et adresse e-mail.

  • Lorsque ce formulaire est soumis dans le fichier RegistrationServlet, vous obtenez tous les attributs de la couche de vue à la couche de gestion où vous passez   les attributs 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 finalement à la couche de persistance.

DTO était principalement utilisé pour transférer efficacement des données sur le réseau, même 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 de données fixe et est similaire à un enum 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 des 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 ne dispose pas de ces restrictions.


48
2017-10-23 10:31



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 Entier, Argent, etc.

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

Java Beans: requiert un Java Class être sérialisable, avoir un no-arg constructeur et un getter et setter pour chaque champ


34
2017-07-15 09:49



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

le Spécification JavaBeans Dans Java 1.0, Sun tentait de manipuler des objets Java dans un IDE qui ressemblait à 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és qui ont suivi la convention de nommage appropriée
  3. Serialisable
  4. Peut-être que 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, le pooling, 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 emballeraient en vrac et les expédieraient.

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


22
2017-10-23 10:17



POJO : C'est un fichier java (classe) qui ne prolonge ni ne met en œuvre aucun autre fichier java (classe).

Haricot: 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: C'est un fichier java (class) qui peut être constitué de variables public / private / default / protected et qui peut ou non étendre ou implémenter un autre fichier java (class).


2
2017-08-17 05:00



Premier Talk About

Classe normale  - cela signifie que toute classe définit qui est normalement en Java, il signifie que vous créez différents types de propriétés de la méthode etc.
Haricot - Bean n'est rien, ce n'est qu'un objet de cette classe particulière utilisant ce bean, vous pouvez accéder à votre classe java comme objet..

et après cela parler de dernier POJO

POJO - POJO est cette classe qui n'a aucun service, elle a seulement 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. Il s'agit d'une forme abrégée d'objet Java simple.


1
2017-12-15 09:25