Bonjour,

Je précise d'emblée que j'ai lu la page http://hibernate.org/42.html mais que cela ne répond pas à ma question.

Le contexte : Développement d'un site en Java 5, nécessitant des batchs d'alimentation. Hébergement prévu : du tomcat 5.5, utilisation de JSP voire d'un framework ( struts, spring..). Pour la persistence : hibernate. Je me place dans un cadre proche d'un projet pro pour essayer d'éclaircir certains points..

Je souhaite encapsuler hibernate via des DAO pour pouvoir simplement basculer un jour la couche d'accès aux données vers une autre solution si nécessaire ( EJB3.0, ou plus simplement d'hibernate 2.1 vers hibernate 3). Rien d'anormal jusque là.

Pour les objets DAO, je ne gère pas session et transaction à ce niveau là, comme préconisé dans la doc. Ca permet au métier de pouvoir appeler plusieurs méthodes de la couche DAO sur une seule et même transaction (exemple: débit sur un compte et crédit sur un autre).
Toujours pas de problème.

Ce qui m'ennuie, c'est la gestion transparente de la session et de la transaction. Les exemples manipulent tous la SessionFactory et la session hibernate.. (que ce soit le ServletFilter ou les autres) Ce n'est pas la meilleure marque d'indépendance vis à vis d'hibernate. Cela semble indiquer que tous les sites webs associés, batchs etc.. vont avoir besoin d'utiliser ces objets pour gérer la transaction -> Le jour où je veux migrer, je dois reprendre aussi tous ces éléments pour les modifier, et pas uniquement changer ma couche DAO. (Même En admettant que mon métier soit distribué si j'utilisais des ejbs, il n'en reste pas moins que mon métier devrait utiliser hibernate directement pour ses sessions et transactions)

Vous êtes vous déjà posés cette question, et surtout avez vous une réponse ? Pour moi, ces exemples cassent l'indépendance des couches métiers et/ou présentation de la couche DAO. Bref, pas la meilleure solution dans un monde n-tier.

Merci d'avance, toutes mes recherches sont restées vaines jusqu'à présent.

Bonjour Airness,

J'ai été amené à travailler sur une problématique similaire avec NHibernate (donc en .NET et pas Java mais l'idée reste la même).

La solution à laquelle je suis arrivé est d'encapsuler les objets session et transaction de Hibernate dans ma propre classe que j'ai nommée "ContexteMetier". Le code appelant la DAL travaille donc uniquement avec cette classe qui implémente les opérations de base (commit, rollback ...) sans jamais voir qu'il y a des classes hibernate derrière.

Ainsi, si le besoin de changer de technologie d'accès aux données se fait sentir, il suffit de reprendre cette classe ContexteMetier en plus des DAO et le changement sera transparent.

De plus, cette technique permet de petites astuces sympathiques en créant plusieurs variantes de ContexteMetier qui surchargent certains comportements dans des cas particuliers.

J'espère que cette piste te seras utile.


Renaud Martinon

Bonjour Airness,

J'ai été amené à travailler sur une problématique similaire avec NHibernate (donc en .NET et pas Java mais l'idée reste la même).

La solution à laquelle je suis arrivé est d'encapsuler les objets session et transaction de Hibernate dans ma propre classe que j'ai nommée "ContexteMetier".
Le code appelant la DAL travaille donc uniquement avec cette classe qui implémente les opérations de base (commit, rollback ...) sans jamais voir qu'il y a des classes hibernate derrière.

Ainsi, si le besoin de changer de technologie d'accès aux données se fait sentir, il suffit de reprendre cette classe ContexteMetier en plus des DAO et le changement sera transparent.

De plus, cette technique permet de petites astuces sympathiques en créant plusieurs variantes de ContexteMetier qui surchargent certains comportements dans des cas particuliers.

J'espère que cette piste te seras utile.

Renaud Martinon

Merci pour ta réponse.

J'ai déjà pensé effectivement à cette solution, mais je suis surpris qu'il n'y ait pas plus d'informations sur ce sujet. Ca n'enlève rien à la pertinence de ton post :-)