Hibernate : augmenter la productivité avec un GenericDao
Par philippe voncken, samedi 20 février 2010 à 09:07 :: Java :: #149 :: rss
Je vois de ci de là beaucoup de développeurs implémenter des DAO en masse pour chacun de leurs objets du domaine.
Une bonne pratique dans la programmation n-tiers est de regrouper les requêtes dans une couche de service. On utilise alors un generic DAO que l'on va instancier dans un service, en lui donnant en paramètre un type de classe, afin de l'utiliser facilement.
Lorsque l'on tape generic dao dans google on tombe sur pas mal de ressources.
D'abord sur le site d'Hibernate où se trouve un exemple qui incite à étendre un generic DAO afin d'implémenter moult dao spécifique. Le problème de cette approche est de dispatcher les implémentations qui permettent de trouver ou persister l'information dans diverses classes. Ceci entrainera une diminution de la cohérence de la couche DAO avec l'augmentation de la complexité de l'application.
Le second lien amène vers un article intéressant d'IBM qui traite la problématique du DAO de manière plus complète, même si les exemples utilisent des fichiers de conf xml au lieu des annotations. Disons qu'avec des annotations ce serait mieux. Mais on reste dans l'approche de l'implémentation du DAO pour chaque Pojo.
En passant, on tombe sur le projet Hibernate Generic D.A.O. Framework qui m'a l'air d'être très intéressant et prometteur. Si ca peut nous éviter quelques lignes de code compliqué pourquoi s'en priver ? Il faut voir si c'est facile à configurer, mais à prioris on doit surement injecter au framweork la sessioFactory Hibernate. Si ce n'est que ca, une annotation et c'est réglé.
Une alternative qui augmente la cohérence du code de persistence
Avoir un dao généric permet de diminuer le nombre de ligne de codes car toutes les méthodes d'accès standards sont disponibles dans une seule classe. La couche de service ne va se concentrer ainsi que sur des méthodes plus complexes. On va ainsi regrouper toutes les requêtes Hql dans un même objet de service qui correspondra à un Objet du domaine représentatif d'un module.
La rigueur du découpage applicatif, à la DDD, en module est l'une des clés du succès d'un projet informatique.
Commentaires
Aucun commentaire pour le moment.
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.