Discussion :

[Grumium]

Bonjour,

Je suis en train de développer une application en client lourd à l'aide d'Hibernate pour gérer la persistence de mon modèle et sa navigation.
Et je buche sur la manière de résoudre le problème suivant : Lorsque j'ouvre une vue, pour afficher une information, dans mon application, la vue interroge un service qui lui retourne les informations souhaitées à l'aide des entités Hibernate et les affichage. Si j'ouvre maintenant une autre vue sur une information de la première vue, celle-ci lui fournit l'entité Hibernate détachée et essaye de travailler dessus or étant détachée en cas de lecture d'une relation j'ai l'exception LazyInitializationException chose qui est normale.

Je me demande si la meilleur solution, c'est d'avoir toujours une session ouverture (là je ne sais comment faire) ou de rattacher sans arrêt les objets à chaque nouvelle manipulation ou si il y a une autre solution plus standard ?

Merci d'avance pour vos messages

[DevServlet]

Code :

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

celle-ci lui fournit l'entité Hibernate détachée et essaye de travailler dessus or étant détachée en cas de lecture d'une relation j'ai l'exception LazyInitializationException chose qui est normale.

Pas clair ton explication, si le service fournit une entite c'est que celle ci est attachée à ton contexte de persistance, et puis ton erreur ne vient pas d'un pb d'attachement d'entité, à mon avis ca vient du fait que tu sois en politique LAZY et que t'essaie d'obtenir une entité liée à une autre. essaie de mettre ta politique de mapping en EAGER et reteste voir.

[tchize_]

tout dépend de ton client lourd. T'as le choix entre une session permanent (avec les emmerde et les avantages qui vont avec) ou rattacher systématiquement tes objets (avec un lock par exemple) avant de les afficher. La trousième possibiltié est de ne passer que l'id de l'objet à travailler à l'interface, elle repompera un nouvel objet dans la db :p.

Souvent on opte pour la première dans un client lourd, par facilité. Attention cependant à la gestion des transaction. Si tu détache pas tes objets, tu risque de voir toutes les bidouiles du user persistées au premier commit !

[Grumium]

Je ne peux pas utiliser ta troisième solution étant donné que j'aurai d'autres vues qui mixeront des objets persistés ou non.

Pour le rattachement, je ne sais pas comment m'y prendre pour rester propre, je m'explique : je trouve ça bizarre que ma couche service intégre des services me permettant de rattacher des objets à Hibernate.

[tchize_]

Je ne peux pas utiliser ta troisième solution étant donné que j'aurai d'autres vues qui mixeront des objets persistés ou non.

Pour le rattachement, je ne sais pas comment m'y prendre pour rester propre, je m'explique : je trouve ça bizarre que ma couche service intégre des services me permettant de rattacher des objets à Hibernate.

qu'est-ce que ca aurait de bizzare?

[Grumium]

Pour moi la couche service n'a pas pour rôle de gérer le rattachement d'objet étant donné que c'est une contrainte liée à l'utilisation d'Hibernate et que sont utilisation doit être masquée par la couche d'accès au données.

Ca résumerait à projeter un service fournit par la couche d'accès au données au niveau service pour que l'ihm y ai accès

[tchize_]

le terme "service" est vague (tu parle probablement de la couche business). De plus, le service n'a pas à fournir des fonctionnalité de rattachement. Il peux fournir des fonctionnalité de haut niveau qui gèrent automatiquement les rattachement à une session en cas de besoin. De toutes facons, tu devra traiter le fait que ce sont des données dans une session hibernante à un moment ou un autre. Si tu veux un IHM indépendante de la session, il va falloir lui passer autre chose que des objets Hibernate. Tu ne peux pas voiloir manipuler des objets hibernate et en même temps vouloir ignorer la session. A un moment donnée la session va entrer en ligne de compte.

Comme je l'ai dit tu peux garder une session globale, mais t'aura alors le problème des cascades et des flush. Le user sauve et commit l'écran X et les données qu'il a modifiées aux écrans X et Y, par le biais du flush hibernate, se trouvent commitées dans la DB, tout cas parce que les objet avaient été modifiés.

[henpower]

J'ai eu une préoccupation semblable dans l'un de mes projets pour lequel je tenais absolument à masquer l'implementation Hibernate de ma couches d'accès données et metiers au developpeurs d'IHM, de peur de les effrayer avec l'apprentissage d'hibernate. Pour cela j'avais définit une surcouche (eh oui !) Hibernate constitué d'un ensmeble d'interface java, chacune de ces interface étant implementer par un POJO connu d'hibernate. Je me suis alors retrouver à surcoucher la notion de Session (j'encapsulais les problèmes liées au détachement d'objet dans ma session), de transaction dans Hiernate. Tout cela a bien fonctionné. Le seul bemol de cette solution est qu'elle m'a demandé d'aussi surcoucher la gestion des Exceptions Hibernate. Ca demmande trop de rigueur mais ca fonctionne. J'avais d'ailleurs implémenté dans ma Session la gestions associations bidirectionnelles d'un seul coté de l'association (Hibernate imposant de notifier les deux membres de l'association).
J'avoue néanmoins que tout ca a été lourd comme boulot.

[Grumium]

Comment fait-on pour ne jamais fermer la session dans un développement d'aplication lourde étant donné que j'utilise spring pour gérer les transactions et l'ouverture et fermeture de session.