Discussion :

[_skip]

Bonjour,

Il y a une question qui me passe sans arrêt par la tête à laquelle j'ai du mal à trouver une bonne réponse.

En principe, est-ce que vous considérez les POJO hibernates que vous avez mappés comme des objets métiers à part entière ou est-ce que vous les prenez plutôt comme un moyen simple de charger/écrire dans votre base de donnée?

La question en fait, c'est de savoir si vraiment c'est jouable de laisser les objets hibernate se faire éditer par l'utilisateur de l'application dans une UI, par exemple en étant lié à une table ou un formulaire en JSF.

Si vous avez une méthode métier style getUsers() qui fait appel à votre DAO hibernate qui vous retourne une série de proxy, c'est quand même risqué de les retourner comme tel à l'UI puisque la moindre opération qui demande un accès à la DB (chargement d'une association) risque de tout faire cramer. Sans comtper qu'on ne sait pas trop comment ces proxy se sérializent dans un sens ou l'autre.

D'un autre coté c'est très convenable de charger une liste d'utilisateurs et de la lié direct à un composant d'affichage, sans la copier propriété par propriété dans un autre objet exactement identique....

Bref j'aimerai savoir comment vous utilisez les objets mappés d'hibernate dans votre application.

[tchize_]

dans un environnement web, c'est assez facile. tu peux envoyer direct les objet hibernate sur l'iinterface. Et pour cause, ils auront une durée de vie égale à la requete -> pas de soucis à gérer la session en backend. Pour ce qui est de l'edition, c'est plus compliqué Ici on a des objet Hibernate en edition directe sur l'interface, mais ca pose des problèmes. Exemple: on fait une requete HQL -> hibernate fait un flush -> on écrit sur la db alors que le user a toujours pas fait 'save'.

Donc là on a péché par excès de fadisme, on aurait du remettre une couche pour bien faire les choses au niveau édition Mais comme c'est compliqué à faire et chiant on va trouver une bidouille (les requetes hql se feront sur une sessions séparée de la session d'edition :p)

[_skip]

J'ai un peu le même problème, j'ai des entités peu complexes que j'aimerai pouvoir lire, lier aux champs d'un formulaire pour édition, puis sauver de façon simple.

J'ai aussi voulu travailler en session per request, mais j'ai l'impression de perdre complètement le contrôle face à toute la magie qui se cache derrière les proxys retournés par hibernate, le commit automatique des changements parmi eux (pire chose au monde pour moi) et le danger permanent de ramasser une exception parce qu'on se rappelle plus si le POJO a été chargé avec sa relation ou non.

En fait j'ai de plus en plus l'impression que jamais un POJO hibernate ne devrait survivre plus longtemps que la session qui l'a chargé, ce qui correspond dans mon cas à un appel à une méthode business (une transaction métier donc).
Une fois hors de ce cadre, je ne contrôle plus rien, je transmet les POJO (qui sont des proxys) à l'UI, des exceptions peuvent survenir là ou je ne les attend pas... Bref ça me donne un sentiment d'être sous un plafond qui menace en permanence de s'effondrer.
De l'autre côté, lorsque j'essaie de rattacher les objets à une nouvelle session, si c'est un Group contenant une collection d'objet User dans laquelle j'ai ajouté ou supprimé des éléments, hibernate ne saura plus ce qui est à supprimer ou à modifier...

Bref tout ça me pousse dans la direction du DTO mais en même temps ça me coûte beaucoup de copier mes objets hibernates dans des objets DTO sans ajouter de fonctionnalités....

En gros je galère conceptuellement là...

[tchize_]

là t'as tout a fait raison, ton POJO, si tu utilise du lazyloading, ne devrais plus jamais être utilisé après la fermeture de la session qui l'a généré. En ce qui nous concerne, la session hibrenate dure toute la requete, donc ils est complètement disponible.

Il n'y a pas de commit automatique en hibernate. Il y a par contre des flush automatique. C'est pour la bonne cause, certaines requete ne peuvent pas être satisfaites de manière cohérente tant que les modifs n'ont pas été flushé sur la db.

Exemple: je modifie X en faisant un setName(). ensuite je fais une reqete hql pour avoir tous les X tel ques X.name=...., hibernate est bien obligé de flusher dans la db si tu veux que le résultat du hql soit cohérent. Encore une fois, ca veux pas dire c'est stocké, tant que t'as pas fait le commit sur la transaction (et à condition d'avoir bien fait une transaction :p)

Pour le auto_flush, c'est aussi configurable (tu peux forcer hibernate à ne jamais en faire)

[_skip]

là t'as tout a fait raison, ton POJO, si tu utilise du lazyloading, ne devrais plus jamais être utilisé après la fermeture de la session qui l'a généré. En ce qui nous concerne, la session hibrenate dure toute la requete, donc ils est complètement disponible.

Juste, mais est-ce que tu oses le conserver dans une session ou un request bean pour autant?

Sinon t'as raison mais en fait ce n'est pas vraiment le flush qui me pose soucis. Ce que j'ai appelé faussement commit automatique était en fait la particularité qu'un POJO modifié puisse avoir ses changements persistés sans un appel vers une méthode Save ou autre de ma part.

[tchize_]

dans une session, non.

Mais ils sont accessible comme request scope bean pour que JSF fasse l'affichage

(le tout est de fermer la session hibernate après l'affichage jsf et là, aucun soucis d'exception)