Maîtrisez la création d’une couche de service pour vos applications hibernate. Comprenez les limites de la couche service mise en oeuvre dans notre tutoriel N°2. Déléguez des opérations CRUD à une couche DAO. Déléguez ceratines opérations métiers (comme la comparaison de 2 objets métiers) à des classes spécialisées.
Objis, spécialiste de la formation Java, est heureux de vous offrir ce
tutoriel, extrait de séances pratiques de la formation HIBERNATE dispensée par Objis.
Les + objis
70% de travaux pratiques
Clé USB avec tous les outils utilisés + Corrigés TPs
Bilan pédagogique individuel + conseils
Prérequis, outils et versions
Tutoriel Hibernate N°2 : votre première application hibernate
Liens utiles
+ de 100 tutoriaux java/jee Objis
Tutoriaux HIBERNATE Objis
Objis, spécialiste formation java depuis 2005
Site hibernate (javadoc, faq)
Documentation (chap. 10) : working with objects
Objectifs
Créer une couche DAO hibernate
Mettre en œuvre Designs patterns avec Hibernate : Service locator, DAO, Business Delegate
Programme
Contexte
Partie 1 : Architecture 1
Partie 2 : Problème de l’architecture 1
Partie 2 : Architecture 2
Durée
30 min.
Contexte
Dans notre tutoriel hibernate N°2 « Votre première application hibernate », vous avez mis en œuvre une couche de service permettant de réaliser la création d’une formation :
corrige_tutoriel2_test_couche_service_demohibernate
Nous allons analyser les lacunes de cette approceh et proposer une meilleure architecture.
Partie 1 : Architecture N°1
Soit l’architecture suivante (qui est celle du tutoriel 2, dont le code est ci-dessus)
avec une couche Service ressemblant à ceci :
Expliquez le code
Identifiez les lacunes de cette architecture.
Partie 2 : Problèmes de l’architecture 1
PROBLEME 1 : la ‘couche service métier’ est trop ‘technique’. En effet, en plus d’opérations purement ‘métier’, notez la présence de gestion bas niveaux (plomberie) liée aux exceptions et gestion Session.
PROBLEME 2 : C’est une bonne pratique que la couche métier ne soit pas liée à une implémentation quelconque de persistence. Or ici, si on devait changer stratégie de mapping (par ex. remplacer hibernate par Toplink ou iBatis), il faudrait aussi ‘toucher’ à la couche service.
PROBLEME 3 : mise en œuvre de l’anti-pattern ‘Session per Operation’ : il y a une session spécifique par méthode métier, ce qui ne permet que de travailler avec des objets détachés hibernate. En particulier, dans le cas d’une récupération d’objet, ce dernier sera détaché sur au session.close(). Il est recommandé d’utiliser la même session hibernate pour un ensemble de méthodes métier
Partie 3 : Architecture 2
Nous allons proposer une architecture permettant de libérer cette couche de :
— la gestion des exceptions
— la manipulation de Sessionfactory/Session.
Idéalement , on utilisera une nouvelle architecture mettant en oeuvre
— l’utilisation du design pattern DAO
— l’utilisation du design pattern Business Delegate (pour déléguer à d’autre classes la réalisation de taches type accès données, comparaison d’objets…)
— l’utilisation d’interfaces
Considérez l’architecture suivante (v2)
Expliquez.
QUESTION : Comment passer la Session à la couche Dao ? Comment utiliser cette même session dans une méthode de la couche Dao ?
Le tutoriel hibernate N°10 nous fournit 2 implémentations possibles :
— le Filtre HTTP
— le Contexte de servlet
Session locale au thread
Dans ce type de contexte, une autre solution est est possible le pattern pattern ThreadLocal : la classe java.lang.ThreadLocal créée une session accessible dans le thread applicatif courant. Cela est particulièrement utile en environnement multithread, comme applications web.
Etape 1 : paramètre current_session_context_class
Dans le fichier de configuration hibernate.cfg.xml, positionnez la paramètre current_session_context_class à la valeur « thread ».
Hibernate va vous rendre un service : gestion automatique de la création de la session et fermeture automatique de la Session suite à un tx.commit().
Etape 2 : utilisation de getCurrentSession()
Le code suivant est rigoureusement identique à celui plus haut :
Suite au paramétrage de hibernate.cfg.xml, l’appel de la méthode getCurrentSession() crée une session si celle si n’existait pas, et affecte cette session au thread courant.
De plus l’appel explicite de session.close n’est plus nécessaire.
ANALYSEZ les logs et comparez. Montrez qu’il y a toujours une session ouverte et fermée.
Délégation accès données au DAO
Nous allons rendre la couche service plus ‘propre’ en déléguant tous les accès au données à une couche d’accès aux données matérialisée ici par classe FormationDao.
Le code du gestionnaire devient :
Le code de FormationDao (méthode save()) :
corrige_tutoriel2_test_couche_service_delegation_dao-2
Délégation comparaison d’objets à un Comparateur
Il est fréquent de devoir comparer des objets métiers. Nous allons rendre la couche service plus ‘propre’ en déléguant toutes les comparaisons à une classe dédiée Comparateur.
Gestionnaire de formation
Comparateur
Conclusion
Dans ce tutoriel, vous avez mis en œuvre une bonne pratique pour la création d’une couche d’accès aux données avec hibernate. Vous avez également mis en œuvre le pattern ‘Session locale au thread’ ThreadLcal, facilitant l’utilisation dans les méthodes du DAO d’une même session hibernate que celle de la couche service.
