Hibernate et pattern DTO

Je me posais également la question sur les DTO car j'ai un problème de LazyLoading (cas du chargement du paramétrage BDD au démarrage de l'application donc en scope Application)

Cet article me rend perplexe et devrait alimenter un peu plus les débats.

http://martinfowler.com/bliki/LocalDTO.html

Etes vous en accord avec cet article ?

Si tu peux préciser les points un tout petit peu... :aie:

DTO ou pas est un vieux débat... et beaucoup de choses ont déjà été dites...

Personnellement, dans une architecture à base d'EJB (entity, stateless, JTA) (et sans SEAM), j'estime que les DTOs sont une excellente réponse au problème de détachement implicite des objets à la sortie du conteneur d'EJB.
A moins d'utiliser systématiquement du Fetch.EAGER sur les sous-objets, on se retrouve très vite confronté au NullPointerException dans la couche de présentation (IHM).
L'avantage avec les DTOs c'est qu'on envoie un graphe d'objets lié à la vue demandée, tout y est, rien de plus...
Un autre avantage réside dans l'indépendance de l'application (métier) vis-à-vis de la couche de présentation, on n'a que des "adaptateurs". Les données peuvent changer sans avoir à retoucher une ancienne application... et que dire quand il s'agit de données utilisées dans un web-service... Là, l'utilisateur n'est même plus de la société qui développe...

Maintenant, pour une petite application (à usage unique si je puis dire), sans EJB, il y a d'autres moyens pour contourner le lazy loading comme par exemple l'acquisition en début de request d'une session et la libération à la fin de la réponse.
Là, le DTO n'a plus vraiment d'utilité...

Bref, un avis de plus... ;)

J'ai personnellement jamais trouvé de solution qui me donne satisfaction. Je ne voulais pas utiliser des DTO pour ne pas créer de pâles copies de mes objets d'entités, et je pouvais pas vivre avec ce risque de laisser les entités survivre à leur session et exploser n'importe quand.

Ma solution qui n'en est pas une, a été carrément de revenir à iBatis et du POJO. :aie:
Lorsqu'un simple affichage UI est nécessaire, je crée des vues spécialisées, lorsqu'un comportement métier est impliqué (édition), j'encapsule ou je convertis le POJO dans un objet plus riche et plus métier.

C'est du travail supplémentaire mais au moins je n'ai aucune surprise avec des proxys, des chargements qui pètent à la gu... et je me casse pas à créer tous mes objets à double et me farcir la conversion de type entre les couches...

Citation:

---

Envoyé par OButterlin

L'avantage avec les DTOs c'est qu'on envoie un graphe d'objets lié à la vue demandée, tout y est, rien de plus...
Un autre avantage réside dans l'indépendance de l'application (métier) vis-à-vis de la couche de présentation, on n'a que des "adaptateurs". Les données peuvent changer sans avoir à retoucher une ancienne application... et que dire quand il s'agit de données utilisées dans un web-service... Là, l'utilisateur n'est même plus de la société qui développe...

---

Plus d'abstraction en effet, si on peut estimer que des changements majeurs dans la source de données ne remettent pas en cause les couches supérieures. Je pense toujours personnellement au passage vers du webservice qui rajoute des contraintes de performance et de logique de requêtage qui ne sont pas les mêmes avec une BDD locale par exemple.

Dans ton cas, est-ce que vous devez créer ces adaptateurs manuellement? Enfin déjà s'agit-il d'adaptateurs ou plutôt de convertisseurs?

Citation:

---

Envoyé par OButterlin

Maintenant, pour une petite application (à usage unique si je puis dire), sans EJB, il y a d'autres moyens pour contourner le lazy loading comme par exemple l'acquisition en début de request d'une session et la libération à la fin de la réponse.
Là, le DTO n'a plus vraiment d'utilité...

Bref, un avis de plus... ;)

---

Mais si ton objet hibernate survit à la requête, le cas ou tu l'auras lié à une interface graphique pour édition, il survit également à la session et devient donc dangereux... Non? :question::

Citation:

---

Envoyé par _skip

Mais si ton objet hibernate survit à la requête, le cas ou tu l'auras lié à une interface graphique pour édition, il survit également à la session et devient donc dangereux... Non? :question::

---

Non, il survit en tant qu'objet détaché puisque la session aura été fermée. Il redevient un simple objet en quelque sorte...
A moins que le danger dont tu parles ne soit lié à l'occupation mémoire (?), mais là, c'est la problématique standard des applications web (session ou request).
Dans le cas "request", à la fin de la phase de "rendu", l'objet est détruit.
Par contre, si on accède à une propriété "lazy-loading" non initialisée, on n'a pas de plantage puisqu'à ce moment, il est encore attaché...

Citation:

---

Envoyé par OButterlin

Non, il survit en tant qu'objet détaché puisque la session aura été fermée. Il redevient un simple objet en quelque sorte...
A moins que le danger dont tu parles ne soit lié à l'occupation mémoire (?), mais là, c'est la problématique standard des applications web (session ou request).
Dans le cas "request", à la fin de la phase de "rendu", l'objet est détruit.
Par contre, si on accède à une propriété "lazy-loading" non initialisée, on n'a pas de plantage puisqu'à ce moment, il est encore attaché...

---

Je peux me tromper mais il me semblait que si tu utilises la solution qui ouvre la session à l'aide d'un filtre au début de la requête http et qui la ferme au moment ou la requête se termine. L'objet que tu auras chargé et lié à ton UI graphique explosera si tu essaies lors du postback suivant de toucher une de ses lazy property.

Ou alors la configuration dans laquelle j'avais fait ces tests étaient pas la bonne...

Tu parles des listes paginées ?

N'importe quel objet créé par hibernate qui survit à la session (au sens hibernate). Donc par exemple qui est retenu dans une propriété d'un request bean JSF pour être édité.
Un objet "Customer" que tu charges et affiche dans un formulaire JSF par exemple.

A l'arrivée de l'utilisateur sur la page d'édition tu fais un (code simplifié):

Code:

---

1 2 3 4

BeanJsf { private Customer customerToEdit = HibernateService.getCustomerById()... }

---

Puis la page est rendue et afficher à l'utilisateur, qui soudain clique un bouton et déclenche un postback

Code:

---

1 2 3 4 5 6 7

BeanJsf { void button_action() { customer.getBills(); //oups... } }

---

Ensuite, dans un postback sur la même page, un clic sur un bouton déclenche un customer.getBills(), là ça devrait cramer.

Évidemment... si tu ne le rattaches pas à une session et que la propriété n'a pas été chargée, ça plantera...
Mais tu peux faire un session.refresh(objet) dans ce cas... ce sera toujours mieux que de garder une connexion ouverte par session (HttpSession)

Juste, mais c'est un risque et il me semble qu'il introduit une certaine *vulnérabilité* ainsi qu'une forme de couplage entre les couches.

De plus il m'a semblé constater que du côté du change tracking dans les collection membres (notamment celle ou l'on souhaite les delete-orphans), cela posait problème.

D'ou l'intérêt pour moi des gens de passer par une couche d'objet non-hibernate pour l'édition et de limiter ce dernier à la communication avec la DB, s'assurant qu'aucun objet ne survive la session.
Mais j'avoue je ne sais pas à quoi ressemble *une bonne application utilisant hibernate dans les règles de l'art*.

Citation:

---

Envoyé par _skip

...
Mais j'avoue je ne sais pas à quoi ressemble *une bonne application utilisant hibernate dans les règles de l'art*.

---

Et moi donc :mouarf: J'ai fait des applications dans les 2 approches, mais de là à dire qu'elles sont dans les règles de l'art (ou de chaque art)... ce serait présomptueux.

D'un point de vue "isolation", il me semble que l'approche DTO est bien meilleure. Charge à l'objet "métier" de convertir en objet(s) persistants...

Je pense que c'est ce que je ferais moi aussi si je devais utiliser à nouveau hibernate. La seule chose qui m'embête c'est la perte de performance due à la transformation des collections chargées sous forme d'objet hibernate en autre chose.
Cependant, tu as au moins le mérite de pouvoir bien contrôler ce qui se passe au niveau de tes accès données puis de pouvoir implémenter des logiques d'édition et de modification coté UI qui ne sont pas dépendantes d'hibernate, et du relationnel en général.

Dans la mesure où tu créeras un graphe d'objets (DTO) par IHM, tu auras la possibilité de mettre exactement ce dont tu as besoin...
Mais ça fait plus de travail...:calim2:

J'avoue être toujours aussi sceptique quant à l'utilisation de ce pattern.
J'ai déjà utilisé Hibernate dans des projets Web et Swing et je n'ai pas ressenti le besoin d'y mettre une couche de DTO.
Comme j'utilise la version xml, je n'ai pas de dépendance envers Hibernate dans mes pojos.
Et surtout, j'évite une couche supplémentaire, à mon avis inutile.

Si l'usage que tu en fais n'implique pas cette "peur" que ça explose dès que tu touches une propriété au mauvais moment, tu aurais en effet tort de rajouter une couche.

Citation:

---

Envoyé par fr1man

J'avoue être toujours aussi sceptique quant à l'utilisation de ce pattern.
J'ai déjà utilisé Hibernate dans des projets Web et Swing et je n'ai pas ressenti le besoin d'y mettre une couche de DTO.
Comme j'utilise la version xml, je n'ai pas de dépendance envers Hibernate dans mes pojos.
Et surtout, j'évite une couche supplémentaire, à mon avis inutile.

---

Ce n'est pas parce que tu utilises la version xml (enfin, je suppose que tu parles des hbm.xml) que tu n'as pas de dépendance.
Il y a également une dépendance hibernate entre ces fichiers et les pojos (ce qui normal d'ailleurs)

Maintenant, une fois encore, pour des projets simples "one-shot", il n'y a pas (à priori) besoin des DTO, on est d'accord.;)

Oui je parle de fichiers de mappings en xml.
Ben si, je n'ai pas de dépendances.
Mes objets mappant mes tables sont de simples javabean.

Et que le projet soit simple ou pas ne change pas le problème.

Citation:

---

Oui je parle de fichiers de mappings en xml.
Ben si, je n'ai pas de dépendances.
Mes objets mappant mes tables sont de simples javabean.

---

Si seulement... :aie:
Plus à partir du moment ou hibernate les a chargé, perso c'est ça qui me dérange.

C'est le fait que tu aies des proxies qui te pose problème ?

Pour moi, c'est plus un problème de bonne gestion de la session et des données que tu charges ou pas.

Citation:

---

Pour moi, c'est plus un problème de bonne gestion de la session et des données que tu charges ou pas.

---

Alors la bonne gestion c'est quoi? Ne jamais laisser les objets hibernate dépasser la session en terme de portée? Si oui, ça implique que tu utilises d'autres objets justement.

Non, c'est juste qu'après, tes objets ne sont plus liés à ta session.
Il suffit de les rattacher à une nouvelle session, quand tu as en besoin.

Citation:

---

Non, c'est juste qu'après, tes objets ne sont plus liés à ta session.
Il suffit de les rattacher à une nouvelle session, quand tu as en besoin

---

Et c'est là que ça pose un problème à pas mal de gens. Il faut savoir précisément si cela est nécessaire ou pas suivant le contexte ce qui peut être assez lourd lorsque les objets ont une durée de vie de plusieurs requests (dans le cas d'une application web). En plus, si l'objet détaché a été modifié il me semble que tout ce qui est mappéé en delete-orphans, hmm :aie:.

Disons que je ne laisse pas d'objets attachés sur plusieurs requests donc je n'ai pas ce problème.

C'est là je pense la raison pour laquelle tu dis que ça va très bien de faire sans, ton raisonnement est tout à fait logique de dire que ça ne t'apporte rien. :ccool:

Ca fait partie des bonnes pratiques à la base me semble-t-il.

Oui mais c'est délicat lorsque tu souhaiterais faire de tes objets hibernate tes objets de travail (avec de la logique métier à l'intérieur) et non seulement des objets d'accès aux données.
En gros pouvoir les binder par exemple à une interface graphique pour laisser l'utilisateur en éditer les propriétés tout en profitant de cette logique métier que tu as implémenté à l'intérieur, puis ensuite les récupérer dans leur état modifié et les sauver.
Mais ça tourne vite en cuisine :mrgreen:...

Désolé d'interrompre votre dialogue mais voilà mon avis :
Hibernate a deux vocations principales :
- Pouvoir manipuler directement des DataObject plutôt que de recourir aux tables et colonnes de la BDD
- Gérer le lazy loading

Si on mappe avec une DTO et donc on fait sauter le lazy loading et qu'on est obligé de faire un mapping sur nos objets, je ne vois vraiment pas pourquoi on s'est embêté à choisir Hibernate, on peut faire la même chose avec du JDBC...

Alors :
- Soit on choisit Hibernate avec les inconvénients et les avantages qu'il possède
- Soit on prend autre chose

Mais on ne prend surtout pas Hibernate en lui appliquant les mêmes traitements que si on avait utilisé du JDBC...

Citation:

---

Envoyé par sourivore

Si on mappe avec une DTO et donc on fait sauter le lazy loading et qu'on est obligé de faire un mapping sur nos objets, je ne vois vraiment pas pourquoi on s'est embêté à choisir Hibernate, on peut faire la même chose avec du JDBC...

---

Parce qu'il y a encore une sacré différence :mrgreen:.
Hibernate propose du cache, du SQL dynamique, une indépendance (toute relative) avec la DB et des API de requêtage (Criteria) qui sont autrement plus sympathiques que de concaténer à la pogne des morceaux de clause WHERE et de jointures pour ne citer que cela.

Le fait que tu utilises du DTO peut signifier que pour certains objets qui franchissent le scope de ta session, tu décides d'utiliser cette surcouche par besoin d'indépenance envers les mécanismes d'hibernate. Mais il reste peut être un bon pourcentage de code qui n'est pas affecté, je pense pas que si tu fais du DTO pour un besoin précis (de communication) tu sois obligé d'être systématique.

Citation:

---

Oui mais c'est délicat lorsque tu souhaiterais faire de tes objets hibernate tes objets de travail (avec de la logique métier à l'intérieur) et non seulement des objets d'accès aux données.
En gros pouvoir les binder par exemple à une interface graphique pour laisser l'utilisateur en éditer les propriétés tout en profitant de cette logique métier que tu as implémenté à l'intérieur, puis ensuite les récupérer dans leur état modifié et les sauver.
Mais ça tourne vite en cuisine ...

---

Pour ma part, je ne mets pas de logique metier dans mes objets Hibernate, qui sont de simples Javabeans.
Je les bind sans problème à mon interface Swing par sous forme détachée. Quand j'ai besoin de les modifier, je les rattache à ma session et ça roule.
Dans mon cas d'utilisation, je n'ai pas de soucis, mais visiblement, nous n'avons pas les mêmes besoins.

Citation:

---

Envoyé par fr1man

Pour ma part, je ne mets pas de logique metier dans mes objets Hibernate, qui sont de simples Javabeans.
Je les bind sans problème à mon interface Swing par sous forme détachée. Quand j'ai besoin de les modifier, je les rattache à ma session et ça roule.
Dans mon cas d'utilisation, je n'ai pas de soucis, mais visiblement, nous n'avons pas les mêmes besoins.

---

Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.
Bref, rien est parfait...:?

Autre éclaircissement, quand je parlais d'une application one-shot, ce n'était pas lié à la complexité du modèle de données mais au fait que c'est UNE application pour UN client... Là, l'indépendance entre données et "usage/consommation" est moins important, et on a moins besoin des DTO (ce qui ne veut pas dire non plus qu'ils n'ont pas un intérêt).

Sourivore :

Le fait d'utiliser des DTO n'empêche pas d'utiliser le lazy-loading, ça n'a rien à voir. Hibernate encourage fortement l'usage du chargement "lazy" et c'est effectivement une bonne pratique (pour éviter dans certains cas qu'une lecture d'un objet ne charge tout le graphe d'objets de la base pour cause de références circulaires).
Les DTO sont des objets d'échange, liés à un besoin précis (d'une IHM ou d'un web-service par exemple). Tu peux avoir plusieurs DTO pour un groupe d'objets (Hibernate), ça t'oblige à créer des "adapateurs/convertisseurs" mais ça garanti une plus grande indépendance entre données et usage.
Imagine par exemple que tu ais besoin d'utiliser une donnée numérique ou une date sous forme de chaîne (cas pas si rare avec struts lorsqu'on veut gérer correctement la Locale du client), le fait d'utiliser le pojo directement dans l'IHM posera problème -> le DTO est une solution.
Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.

Citation:

---

Envoyé par fr1man

Pour ma part, je ne mets pas de logique metier dans mes objets Hibernate, qui sont de simples Javabeans.
Je les bind sans problème à mon interface Swing par sous forme détachée. Quand j'ai besoin de les modifier, je les rattache à ma session et ça roule.
Dans mon cas d'utilisation, je n'ai pas de soucis, mais visiblement, nous n'avons pas les mêmes besoins.

---

Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.
Bref, rien est parfait...:?

Autre éclaircissement, quand je parlais d'une application one-shot, ce n'était pas lié à la complexité du modèle de données mais au fait que c'est UNE application pour UN client... Là, l'indépendance entre données et "usage/consommation" est moins important, et on a moins besoin des DTO (ce qui ne veut pas dire non plus qu'ils n'ont pas un intérêt).

sourivore :

Le fait d'utiliser des DTO n'empêche pas d'utiliser le lazy-loading, ça n'a rien à voir. Hibernate encourage fortement l'usage du chargement "lazy" et c'est effectivement une bonne pratique (pour éviter dans certains cas qu'une lecture d'un objet ne charge tout le graphe d'objets de la base pour cause de références circulaires).
Les DTO sont des objets d'échange, liés à un besoin précis (d'une IHM ou d'un web-service par exemple). Tu peux avoir plusieurs DTO pour un groupe d'objets (Hibernate), ça t'oblige à créer des "adaptateurs/convertisseurs" mais ça garanti une plus grande indépendance entre données et usage.
Imagine par exemple que tu ais besoin d'utiliser une donnée numérique ou une date sous forme de chaîne (cas pas si rare avec struts lorsqu'on veut gérer correctement la Locale du client), le fait d'utiliser le pojo directement dans l'IHM posera problème -> le DTO est une solution.
Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.

Citation:

---

Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.

Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.

---

C'est un faux problème, cette histoire de lazy loading.
Les DTO ne résolvent rien.
C'est au développeur à savoir ce dont il aura besoin et de charger les bons objets.

Bien sûr que si, les DTO résolvent le problème puisque tu renvois un graphe complet lié à la demande

Mais ils n'apportent rien.
Tu peux très bien charger les données dont tu as besoin, sans DTO.

Si ça consiste pour toi à créer une classe qui est la copie de l'entity et d'avoir une méthode qui boucle sur les enregistrements d'une liste pour accéder au objets sous-jacents, alors oui, ça n'apporte rien...
Mais le DTO n'est pas toujours une copie de l'entity, il peut aussi redéfinir le type d'un champ pour des questions pratiques liées aux limitations de html par exemple ou à un besoin de limiter le volume (utile) de données transférées ou à un besoin d'isoler la consommation d'une donnée par rapport au modèle "physique"...
Et il restera toujours le cas EJB + JTA qui l'oblige presque...

Dans ce cas admettons, mais ça n'a rien a voir avec le lazy loading, ne mélangeons pas tout.

Et pour ce qui est des ejb/jta, je ne vois toujours pas le rapport.
Les DTO étaient "obligatoires" avec les EJB2, pour éviter les allers-retours vers le serveur.
Ce n'est plus le cas maintenant.