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.