POJO, DTO et Beans : je m'y perds

Salut,

Je suis entrain de suivre un tuto sur cet excellent site qui propose de réaliser une aplli java spring/angular.

Je fais beaucoup de confusion sur les objets et leur rôle notamment au niveau des Rest controller où il y a des appels d'objets DTO.
Du coup je me demande :
- est-ce que les java beans sont l'équivalent des DTO vu qu'il n'y a que des getters/setters à l'intérieur ?
- Du coup que sont les POJOs, s'agit-il de la même chose ? J'ai vu qu'il s'agissait d'objets simplifiés à la manière des beans...Bref, je m'yperd.

Merci de votre aide

POJO : Plain Old Java Object (viel objet java simple) - ce sont juste des objets Java tout simple qui heritent ou étende pas une API complexe. Donc un POJO avec des getters et/ou des setters oui c'est un bean. Mais tous les POJO ne sont pas des beans de meme que tous les beans ne sont pas des POJO.

Bean : haricot ou grain (de café - pour rester dans la thématique Java) a l'origine sensé être une manière de décrire des objets qui devaient être manipulables dans des éditeurs graphiques pour permettre une construction de programmes (pas forcement des UI) sans devoir trop taper de code, juste en établissant graphiquement des liaisons entre propriétés de plusieurs objets. A la base on retrouve donc les getters et les setters mais il y a pas mal d'autres choses optionnelles qui gravitent autour, et que la plupart des gens oublient d’implémenter, telles que :

• Le fait d’être serialisable ;
• La gestion des événements pour être prévenu lorsque les propriétés changent de valeur ;
• La gestion des événements pour empêcher le changement de valeur de la propriété ;
• Des descriptions lisibles par les humains pour rendre la chose utilisable dans l’éditeur graphique ;
• Une icône pour représenter le bean dans l’éditeur graphique ;
• etc.

L'aspect manipulation visuelle est passée a la trappe (hors UI builders) et plus personne ne se souvient que ça a été créé pour ça a l'origine. Et clairement un bean observable complet qui implémente toute la foultitude de trucs optionnels dans les spécifications des bean ça peut pas être un POJO.

Pour reprendre une def postée par wax78 et OButterlin (car c'est pas un terme que j'utilise vraiment) :

Citation:

---

Envoyé par wax78

DTO qui veut dire "Data Transfer Object" sont des objets qui vont contenir les données en tant que tel (exemple le DTO Client qui va contenir des propriété genre Nom, Prenom, Adresse, etc). Ils ne contiennent généralement pas de "logique métier"

---

Citation:

---

Envoyé par OButterlin

On commence par le plus simple, le DTO (Data Transfer Object) :
C'est un objet qui défini la structure des informations à échanger, généralement, Serializable.
En gros, c'est l'objet qui circule entre les différentes couches de ton application.

---

Donc oui un DTO qui fait rien d'autre que de stocker des valeurs ben ça peut être un POJO (malgré la présence de la sérialisation*) et s'il a des getters et/ou des setters c'est aussi un bean.

* de toutes manières la sérialisation va passer a la trappe dans les années a venir et il y a d'autres manières de nos jours de gérer la persistance et ce rôle est le plus souvent dégelé a des entités externes dédiées plutôt qu'a l'objet lui-même donc on retombe sur nos pattes.

Merci pour ta réponse très complète

En fait je réalise que c'est plus les objectifs du bean que sa définition qui me posaient problème. Je suis entrain de travailler sur un autre tuto sur OCR pour ne pas les citer qui est très bien fait
Ils définissent les objectifs du bean comme ceci :
- Stockage de données
- Sérialisation pour la persistance
- réutilisation car il ne présente pas de liens avec la couche de présentation et la couche DAO.
- Introspection (je suis entrain de regarder ce concept)

J'avais en effet lu la conversation de wax78 très intéressante
Du coup sur wikipédia ils ont l'air de faire la distinction entre POJO et Bean du fait de la sérialisation :

Citation:

---

Un JavaBean est un POJO qui est sérialisable, a un constructeur sans arguments, et permet l'accès à des propriétés utilisant des méthodes getter et setter dont les noms sont déterminés par une convention simple.

---

Dans le super tuto de Mr Georges Kemayo (merci à lui) , il utilise des objets DTO qui ne sont pas "serializable", , c'est peut être ça qui m'a un peu dérouté.
Ca va encore s'éclaircir avec la pratique

Merci encore

Et pourtant la plupart de ces gens se plantent complètement sur ce a quoi les beans sont destinés:

Citation:

---

Envoyé par JavaBeans specifications 1.01

Introduction
The goal of the JavaBeans APIs is to define a software component model for Java, so that third party ISVs can create and ship Java components that can be composed together into applications by end users.

1.1 Component granularity
There are a range of different kinds of JavaBeans components:

1. Some JavaBean components will be used as building blocks in composing applications. So a user may be using some kind of builder tool to connect together and customize a set of JavaBean components s to act as an application. Thus for example, an AWT button would be a Bean.
2. Some JavaBean components will be more like regular applications, which may then be composed together into compound documents. So a spreadsheet Bean might be embedded inside a Web page.

These two aspects overlap. For example a spreadsheet might live within a composite application as well as within a more normal compound document. So there is more of a continuum than a sharp cutoff between “composite applications” and “compound documents”.

The design centre for beans ranges from small controls up through simple compound documents such as Web pages. However we are not currently trying to provide the kind of high-end document integration that is typical of full function document systems such as ClarisWorks or Microsoft Office. Thus we provide APIs that are analogous to (say) the OLE Control or ActiveX APIs, but we to do not try to provide the full range of high-end document APIs provided by (for example) OpenDoc. However, we do intend to allow beans to be embedded as components in high-end compound documents, and we also expect that some key document suite components (such as word processors and spreadsheets) will also be supported as JavaBean components.

In general we expect that most JavaBeans components will be small to medium sized controls and that we should make the simple cases easy and provide reasonable defaults for as much behaviour as possible.

---

A la base c'etait pour Sun un moyen de faire quelque chose de similaire a COM et OLE de Microsoft.

1. composant atomique d'application manipulable via programmation visuelle (Visual Studio etait le precusseur de ca a l'epoque avec son editeur de proprietes)
2. au contraire des bouts d'applications qui peuvent etre reutilisees et incluses dans d'autres applications plus grosses (ex: des modules et plugins ActiveX pour Microsoft Office)

Et clairement aucun de ces 2 trucs peut etre un POJO.

La partie 1.2 "portability" juste apres dans les specs est encore plus éloquente sur les ambitions (un peu démesurées) de Sun a l’époque de faire des composants universels qui soient réutilisables de partout et directement intégrables dans des environnements natifs sans contrainte aucune. A l’époque tout les vendeurs d'OS, de navigateurs ou encore de plateformes logiciels majeures étaient supposés intégrer des JVM dans leur système au niveau natif ce qui aurait fait que les composants Java auraient été considérés comme des citoyens de 1ere classe et non pas comme des aliens fraîchement débarques et incapables de discuter avec le reste du monde. 23 ans plus tard (le doc date d’août 1997), on sait ce qu'il en est...

Salut et merci encore,

Du coup je reviens un peu aux objets DTO, car il y a un truc qui m'échappe en tant que novice au niveau de leur rôle. J'ai vaguement saisi qu'ils émettent des données à travers
les différentes couches de l'appli comme l'explique Wax78 dans sa réponse, mais plus précisement comment cela fonctionne ?

Est-ce que les DTO récupèrent les données des DAO pour les fournir au client, comme une sorte de passerelle ? Dans quelle couche les retrouve-ton dans une application
architecturée en n-tiers ?
Dans le tuto que je suis entrain de suivre (où l'on créé une appli web java/angular), les DAO sont convertis en DTO qui récupèrent les données au niveau des web services dans les classes controller
comme ceci.

Code:

---

1 2 3 4 5

......................... Customer customer = customerService.findCustomerByEmail(email); CustomerDTO customerDTO = convertCustomerToCustomerDTO(customer); .........................

---

Quel est l'intérêt de faire cela, est-ce que ca permet d'ajouter une couche d'abstraction entre la couche de données et la présentation ?

Les DTO sont "des sacs à valeurs" :mrgreen: - que des membres, pas de logique (autres que les accesseurs/ mutateurs).
La raison c'est parce que la logique de saisie (et validation) des valeurs et la logique d'utilisation (et validation) des valeurs ont été retirées des DTO à cause du découplage et d'avoir ces logiques a 1 seul endroit (dans les couches responsables)

Et c'est ce que tu as écrit dans ton précédent message :zoubi: "réutilisation car il ne présente pas de liens avec la couche de présentation et la couche DAO."
D'ailleurs cela implique que si tu utilises les DTO dans tout ton code, tu peux uniformiser les données dans ton application :zoubi: et les mises à jour vont être répercutés partout (après la suppression de valeurs/ membres peut être douloureuse :whistle:)

A noter que les objets de type Record introduits en preview dans le JDK 14 servent à peu près aux même choses (et sont non-mutables).

Merci,, je n'avais pas vu vos réponses

Je viens de terminer le tuto sur lequel je travaillais, et je conclus que les DTO permettent de transmettre les données à la couche de présentation.

Dans le cas d'un web service de type GET, le DAO est systématiquement converti en DTO pour être exposé à la vue (à l'aide de ModelMapper)
et inversement, lors d'un POST, d'un DTO, on convertit en DAO pour persister en base. De fait les DTO prennent en charge les données et ne font "que" les faire transiter d'un sens
ou dans l'autre à travers les couches de l'appli.
J'espère ne pas dire trop de bétises.
Merci pour cette conversation très instructive, à bientôt

Je pense qu'il y a une confusion, on ne convertit pas un DTO en DAO mais plutôt en Entity. Le DAO est là (généralement) pour gérer la persistance de données.

Quelques autres aspect des DTO :

1- Représentent les données utilisées par l'application cliente

A un instant T, le modèle de données lié à la DB aura un certains nombre de caractéristiques utiles à l'application 1
A T+n, on peut très bien ajouter d'autres colonnes, voir d'autres tables liées pour ajouter de l'information pour une application 2.
Comme le DTO représente une abstraction des données utilisées par l'application, dans bien des cas, aucune modification ne sera nécessaire à l'application 1 pour continuer de tourner.
Bien sûr, une propriété utilisée qui disparaît entraînera une erreur et donc des modifications dans l'application 1 pour que ça continue à fonctionner...

2- Permet de faire des changements de types entre le modèle DB et la couche cliente

Bien souvent, quand on utilise des vieilles base de données, on a des dates sous forme d'entier de la forme yyyymmdd.
Dans l'application cliente, on préfère utiliser un objet Date.
Le DTO permettra d'exposer la date sous forme d'objet Date alors que l'entity l'aura sous forme d'entier.
C'est donc à la méthode de conversion d'un Entity en DTO (et inversement) de faire ce travail (les fameuses méthodes du genre customer2DTOCustomer(Customer customer) et dtoCustomer2Customer(DTOCustomer dtoCustomer)...)

Salut

Citation:

---

Je pense qu'il y a une confusion, on ne convertit pas un DTO en DAO mais plutôt en Entity

---

Oui autant pour moi, je me suis trompé, merci d'avoir rectifié. C'est bien des EJB dont je voulais parler.