Hibernate et pattern DTO

Bonjour à tous,

Je suis en train de me poser une question que vous vous êtes surement tous posée : faut-il oui ou non utiliser le pattern DTO pour copier les objets renvoyés par Hibernate?

Le seul interêt que j'ai trouvé pour l'instant à DTO (ou VO) c'est la séparation des couches et donc la facilité de la transmission des objets retournés par Hibernate (entre les couches ou carrement sur un réseau).

Ce que j'aimerai savoir c'est est-ce que le fait de faire une copie des objets - même détachés- hibernate lui allège son travail. C'est a dire qu'on n'essaye d'utiliser des objets que lui "surveille" ou manipule pour d'autres traitements, en clair est-ce qu'on y gagne en performance?

Si vous avez des experiences, des avis sur la question...n'hesitez pas.

Merci

Utiliser des DTO implique la création de classes supplémentaires qui vont allourdir le projet.
Comme tu l'as dit, je n'utiliserais ce pattern qu'en cas de passages d'objets sur le réseau, comme par exemple par des ejb sessions, pour réduire la quantité d'info transportée.
Pour une utilisation classique, je ne vois pas l'intérêt.
Le lazy loading te permet de charger uniquement les données dont tu as besoin. Je ne pense donc pas que l'utilisation de DTO te permette de gagner en performance.

Pour ma part, bien que je ne connaisse pas assez le pattern DTO, j'ai souvent lu dans des articles qu'Hibernate (ou autre concurrent de persistance) évitait justement l'utilisation d'objets DTO... faut-il après coup, considérer qu'il le remplace ou bien que son travail ne nécessite pas l'intervention d'un tel pattern ... je ne saurais préciser ma pensée à ce sujet ;)

Sur le projet sur lequel je travaille actuellement, nous mappons directement les DTO avec la base de données et nous les utilisons dans toutes les couches (présentation, métier et dao).

Cela diminue le nombre de classe et évite la recopie dans/de des beans de présentation et de bd.

Citation:

---

Envoyé par gronono

Sur le projet sur lequel je travaille actuellement, nous mappons directement les DTO avec la base de données et nous les utilisons dans toutes les couches (présentation, métier et dao).

Cela diminue le nombre de classe et évite la recopie dans/de des beans de présentation et de bd.

---

Hello,

Est ce que cela n'induit pas un certain couplage entre les couches? Que ce passe t'il le jour l'on remplace une couche qui manipule d'autres types d'objets?

A quel niveau sont déclaré tes objets DTO?

Evidement, cela introduit du couplage entre les couches.
Mais, un objet Personne reste une personne que se soit dans la couche DAO, Service ou présentation.

Donc mon objet Personne est le même pour toutes les couches donc cela ne sert à rien d'écrire trois fois (ou plus) la même classe.

L'important est que chaque DTO soit un POJO et ne fasse aucun traitement. Il ne doit pas par exemple modifier le nom de la personne pour le mettre en majuscule ou transforme le nom pour enlever les accents, ...

Si on change l'implémentation d'une couche, l'objet Personne reste une personne. La façon dont on le traite ne change pas sa définition.

A+

Salut,

Tu peux optimiser la mise en cache si tu possèdes un jeu d'objets unique pour Hibernate; ainsi, une même requête executée deux fois de suite, mais utilisées pour deux situations différentes, utilisera le cache.

Les DTO sont donc utiles à ce moment là, pour ne transmettre à tes couches que les informations dont elles ont besoin. En mémoire, ça fait une multiplication d'informations similaires, cependant, la mise en cache et le garbage collector seront plus efficaces ( si tu utilises les mêmes objets dans toutes tes couches, tu risques d'avoir un jour où l'autre des memory leak ).

En ce qui me concerne, je vois Hibernate comme une usine à objets; des gros objets. J'ajoute ces objets en cache la plupart du temps, et ensuite, à partir de ceux-ci ( qui sont donc accédés presque instantanément du fait du cache ) je génère des petits objets volatiles pour les autres couches.

A+

Question : je viens de remarquer que ce sous-forum fait partie de "JDBC" hors, je trouve que c'est pas tout à fait correcte.. Je pense que ce sous-forum devrait directement faire partie du forum java, au même titre que JDBC.

Ou un sous forum Base de données et mapping contenant des sous forums JDBC, Hibernate, EJB, Outils de mapping divers

Citation:

---

Envoyé par gronono

Evidement, cela introduit du couplage entre les couches.
Mais, un objet Personne reste une personne que se soit dans la couche DAO, Service ou présentation.

Donc mon objet Personne est le même pour toutes les couches donc cela ne sert à rien d'écrire trois fois (ou plus) la même classe.

L'important est que chaque DTO soit un POJO et ne fasse aucun traitement. Il ne doit pas par exemple modifier le nom de la personne pour le mettre en majuscule ou transforme le nom pour enlever les accents, ...

Si on change l'implémentation d'une couche, l'objet Personne reste une personne. La façon dont on le traite ne change pas sa définition.

A+

---

Hello,

Oui mais l'interet de faire une architecture en couche te permet de pourvoir moduler celle ci. C'est à dire que tu peux en supprimer une sans impacter les autres. Hors dans ton cas, si tu définis ton objet personne au niveau de la couche de persistance, le jour ou tu la remplaces par une autre qui ne possède pas la même définition de classe ... les autres couches seront forcement impactées et il y aura du refactoring à faire...:roll:

Ou alors il faut passer par des interfaces (qui seront utilisée dans les différentes couches) ..

Après c'est une approche différente du monde J2EE et du modèle MVC..

Citation:

---

Envoyé par KiLVaiDeN

Question : je viens de remarquer que ce sous-forum fait partie de "JDBC" hors, je trouve que c'est pas tout à fait correcte.. Je pense que ce sous-forum devrait directement faire partie du forum java, au même titre que JDBC.

---

Ce sont malheureusement les contraintes des sous-forums et on n'arrivera jamais à une solution idéale.
En l'occurence, Hibernate repose entre autres sur JDBC, tout comme les potentiels sous-forums iBatis, JDO (dans une moindre mesure), etc... qui pourraient être créés si traffic il y avait.

Citation:

---

Ou un sous forum Base de données et mapping contenant des sous forums JDBC, Hibernate, EJB, Outils de mapping divers

---

L'apparition d'un tel forum n'est pas exclue mais n'est pas à l'ordre du jour (difficile d'en faire un sous-forum par manque de terme fédérateur comme JDBC qui a le mérite d'attirer les novices). Ceci-dit, EJB n'a rien à faire là, ce serait plutôt JPA :wink:

Citation:

---

Envoyé par fabszn

Hors dans ton cas, si tu définis ton objet personne au niveau de la couche de persistance, le jour ou tu la remplaces par une autre qui ne possède pas la même définition de classe ...

---

Tu aurais un exemple ? :P
Après tout, le principe d'Hibernate (et plus généralement de JPA) c'est d'annoter un POJO pour se donner les moyens de l'utiliser pour interragir dans une vision objet avec une base de donnée. Donc à priori en changeant par exemple d'implémentation JPA il ne devrait pas y avoir d'impact (d'où l'idée de donner un cadre au mapping O/R).

Maintenant si on sort d'un cadre JPA, la structuration d'un objet va-t-elle vraiment changer ? C'est plutôt à l'outil de mapping d'être flexible ?

Très intéressante comme discussion :wink:

Bonjour à tous,

il y a une semaine maintenant que j'ai posté cette fameuse question "DTO ou pas DTO?". et je dois dire que je n'ai toujours pas trouvé de réponse simple à cette problématique.

D'un coté je suis tout a fait d'accord avec la modularité qu'apporte un tel pattern aux couches que l'on va utiliser, de l'autre l'effort de développement, et l'espace pris en mémoire en vaut-il la peine?

Surtout que finalement le jour où la couche de persistance va changer, la couche métier sera impactée et celle de présentation ne présentera plus les mêmes informations qu'auparavant. Sachant que la relation entre un Pojo Hibernate et un objet DTO est du 1 pour 1....

je reste toujours septique vis-à-vis de ce pattern...:(

Comme tu dis, les DTO ne changeront pas dans une application. Ce qui est succeptible de changer, est la couche d'accès aux données. Donc baser son application entièrement sur Hibernate, serait un grave danger quant à l'évolutivité.

Si tu utilises des DTO, tu n'as plus besoin de te soucier de l'application dans son ensemble; seule la couche d'accès au données est à changer, et il suffit à partir de celle-ci de regénérer les anciens DTO pour que tout fonctionne comme avant.

A+

Citation:

---

Envoyé par KiLVaiDeN

Donc baser son application entièrement sur Hibernate, serait un grave danger quant à l'évolutivité.

Si tu utilises des DTO, tu n'as plus besoin de te soucier de l'application dans son ensemble; seule la couche d'accès au données est à changer, et il suffit à partir de celle-ci de regénérer les anciens DTO pour que tout fonctionne comme avant.

---

Je ne suis pas entièrement d'accord. Si tu changes la couche d'accès aux données, il suffit de changer uniquement le mapping entre les DTO et la base.

Citation:

---

Envoyé par gronono

Je ne suis pas entièrement d'accord. Si tu changes la couche d'accès aux données, il suffit de changer uniquement le mapping entre les DTO et la base.

---

C'est ce que je voulais dire.

Imagine le jour où tu dois enlever Hibernate ( car jugé trop lent ) pour le remplacer par du JDBC pur; si tu n'as pas utilisé de DTO, vive la Cata !

Je ne t'avais pas compris :oops: .

Donc je ne vois pas l'intéret de passer par des objets intermédiaire pour récupérer les infos de la base. Autant les mettre directement dans de DTO, les infos de la base.

L'interêt que je vois, est la mise en cache.

Tu peux mettre un objet contenant toutes les informations en cache, et donc par la suite, générer autant de DTO dans les autres couches que nécessaire, en fonction des besoins.

Exemple : un dossier complet pour une famille.

Tu peux créer ce dossier ( Objet au niveau Hibernate ) avec toutes les collections et informations necessaires.

Ensuite, tu peux utiliser des DTO, pour l'affichage par page des informations; par exemple "information du père" "liste des enfants" et tout ça directement à partir de l'objet en cache.

Voila ma vision des choses o_O

Salut,

quand tu parles d'affichage par page, tu sous entends une navigation dans l'application ? et donc un temps suffisament long pour que ta session Hibernate ait été fermée entre temps. Or à part le cache de niveau 2, il n'y a pas moyen de conserver des données au dela d'une session Hibernate :?

Citation:

---

Envoyé par KiLVaiDeN

C'est ce que je voulais dire.

Imagine le jour où tu dois enlever Hibernate ( car jugé trop lent ) pour le remplacer par du JDBC pur; si tu n'as pas utilisé de DTO, vive la Cata !

---

Je ne vois pas pourquoi ça serait la cata, ma couche de service metier me renverra toujours des objets métier qui auront la meme structure sauf que leurs attributs ne seront plus renseigner par Hibernate mais par une requete JDBC classique. non?

Je parlais bien sûr d'un cache au niveau application. Un système de cache qui soit géré par l'application, et non par hibernate.