A propos des objets de données et de la conception DAO lors de l'utilisation d'Hibernate

Question

J'hésite entre deux conceptions d'un projet de base de données utilisant Hibernate.

Modèle # 1.

(1) Créer une interface de fournisseur de données générale, y compris un ensemble d'interfaces DAO et de classes de conteneur de données générales. Il cache l'implémentation en dessous. Une implémentation de fournisseur de données peut accéder à des données dans une base de données, un fichier XML, un service ou quelque chose d'autre. L'utilisateur d'un fournisseur de données ne doit pas le savoir.

(2) Créez une bibliothèque de base de données avec Hibernate. Cette bibliothèque implémente l'interface du fournisseur de données dans (1). La mauvaise chose à propos de la conception n ° 1 est que, pour cacher les détails de l'implémentation, j'ai besoin de créer deux ensembles de classes de conteneur de données. Un dans l'interface générale du fournisseur de données - appelons-les DPI-Objects, l'autre est utilisé dans la bibliothèque de la base de données, exclusivement pour le mappage entité/attribut dans Hibernate - appelons-les H-Objects. Dans l'implémentation DAO, j'ai besoin de lire les données de la base de données pour créer des objets H (via Hibernate) puis convertir les objets H en DPI-Objects.

Modèle # 2.

Ne créez pas d'interface de fournisseur de données générales. Exposez les objets H directement aux composants qui utilisent la base de données lib. L'utilisateur de la bibliothèque de base de données doit donc être conscient de Hibernate. J'aime le design # 1 de plus, mais je ne veux pas créer deux ensembles de classes de conteneur de données. Est-ce la bonne façon de cacher les objets H et les autres détails d'implémentation d'Hibernate à l'utilisateur qui utilise le fournisseur de données basé sur la base de données?

Y at-il des inconvénients de la conception n ° 2? Je n'implémenterai pas d'autres fournisseurs de données dans le nouveau futur, alors devrais-je simplement oublier l'interface du fournisseur de données et utiliser Design # 2?

Que pensez-vous de cela? Merci pour votre temps!

Answer 1

Je recommande fortement de lire le chapitre 4 "Frapper la base de données" de Spring in Action, 3rd edition, même si vous n'utilisez pas Spring dans votre application. Bien que ma deuxième recommandation serait d'utiliser Spring :-)

Le modèle DAO est un excellent moyen de conserver la logique de base de données et ORM isolée dans l'implémentation DAO, et vous avez seulement besoin d'un ensemble d'objets entité.Vous pouvez y arriver sans Spring, cela prend juste plus de travail pour gérer vos sessions et vos transactions. Si je comprends bien votre message, il s'agit en quelque sorte d'un terrain d'entente entre Design 1 et Design 2. Les H-Objects (les entités que Hibernates charge et conserve) n'ont pas du tout besoin d'un code spécifique à Hibernate. . Cela les rend parfaitement acceptables pour être utilisés comme DPI-Objects. J'ai eu des arguments avec des gens dans le passé qui se plaignent que l'utilisation de JPA ou Hibernate Annotations expose les spécificités d'Hibernate à travers l'interface DAO. Personnellement, je prends une vue plus pragmatique, puisque les annotations ne sont que des métadonnées, et qu'elles n'ont pas d'effet direct sur le fonctionnement de vos classes d'entités.

Si vous estimez que les annotations exposent trop, vous pouvez utiliser la Hibernate Mappings à la place. Alors vos H-Objets sont 100% Hibernate libres :-)

Answer 2

Je recommande le modèle # 2. Construisez simplement des objets de domaine, et laissez Hibernate s'occuper d'eux. N'écrivez pas de classes séparées qui sont persistantes. Hibernate essaie de vous cacher la plupart des affaires de persistance. Vous devrez peut-être ajouter quelques petites annotations à vos entités pour l'aider. Mais ne faites certainement pas de classes séparées.

Vous pouvez avoir besoin de très petites classes DAO. Par exemple, si vous avez une entité Personne, il serait assez courant d'avoir un objet PersonDAO qui sauve une personne. Cela dit, le code à l'intérieur du DAO sera très simple, donc pour un très petit projet, il ne vaut peut-être pas la peine. Pour un grand projet, il vaut probablement la peine de garder votre code de persistance séparé de votre logique métier, au cas où vous voudriez utiliser une technologie de persistance différente plus tard.

Answer 3

Les objets de domaine Hibernate sont des objets POJO simples, donc vous n'aurez pas à créer d'objets DPI séparés, vous pouvez utiliser H-Object directement. Dans DAO, vous pouvez contrôler s'ils proviennent d'Hibernate ou de toute autre chose.