Hibernate et pattern DTO

**sourivore** · 04/09/2009, 00h42

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 ?

**_skip** · 04/09/2009, 09h21

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

**OButterlin** · 04/09/2009, 10h13

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...

**_skip** · 04/09/2009, 10h37

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.

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...

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?

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?

:

**OButterlin** · 04/09/2009, 10h49

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?

:

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é...

**_skip** · 04/09/2009, 11h07

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...

**OButterlin** · 04/09/2009, 11h52

Tu parles des listes paginées ?

**_skip** · 04/09/2009, 12h11

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

**OButterlin** · 04/09/2009, 12h27

É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)

**_skip** · 04/09/2009, 12h51

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*.

**OButterlin** · 04/09/2009, 13h08

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

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...

**_skip** · 04/09/2009, 13h55

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.

**OButterlin** · 04/09/2009, 14h34

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...

**fr1man** · 04/09/2009, 15h09

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.

**_skip** · 04/09/2009, 15h24

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.

**OButterlin** · 04/09/2009, 15h30

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.

**fr1man** · 04/09/2009, 15h34

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.

**_skip** · 04/09/2009, 15h47

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...

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

**fr1man** · 04/09/2009, 15h53

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.

**_skip** · 04/09/2009, 16h03

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.

Hibernate et pattern DTO

Hibernate Java

Discussions similaires

Partager

Partager