Java - couche DAO ou plugin

Question

Je travaille sur le projet JBJF sur SourceForge et nous souhaitons améliorer l'accès à la base de données pour ce cadre. Actuellement, il est semi-flexible, mais l'accès se fait au niveau des tâches.

Nous aimerions configurer une interface simple, de type générique, pouvant héberger l'accès à la base de données depuis / vers JBJF. Ainsi, les classes Framework ne se soucient pas du type de base de données, elles appellent simplement une méthode comme getConnection () et un objet java.sql.Connection revient.

Je me demande ce qui conviendrait le mieux: une couche DAO typique avec une seule interface ou une structure de type Plugin où nous configurons le service de base de données dans un fichier XML et où Framework charge le ou les plugins lors de son démarrage.

tia,

adym

Answer 1

Je commençais à penser que Hibernate était devenu trop gros et gonflé, mais j'ai récemment travaillé sur un projet utilisant la dernière version 3.5 et utilisant JPA et ils l'ont définitivement réduit les autres versions 3.x. Je recommanderais JPA avec Hibernate: -)

L’un des avantages de cette approche est la capacité d’Hibernate à traiter avec plusieurs dialectes de bases de données différents. Notre application fonctionne sur MySQL, H2 et SQLServer sans aucune modification (et ne fonctionnerait probablement que sur les autres bases de données majeures).

Answer 2

que diriez-vous de résumer tout cela et d’utiliser JPA

Answer 3

C'est difficile à dire sans connaître les détails, mais en général, je n'écrirais pas mon propre framework, mais utiliserais plutôt Hibernate ou un outil ORM similaire. Il a déjà défini le code XML pour mapper des objets sur des tables et inversement, peut facilement basculer entre différentes implémentations de bases de données et constitue généralement un excellent outil pour réaliser ce type de tâches.

Answer 4

Les deux options que vous avez énumérées ne sont pas mutuellement exclusives. vous pouvez avoir une couche DAO / Repository à laquelle vous accédez via une interface / API, tandis que les implémentations concrètes sont injectées au moment de l'exécution pour satisfaire vos dépendances.

Par exemple, écrivez une interface WidgetRepository qui définit la partie widget de votre API d'accès aux données. Vous pouvez ensuite fournir un FileSystemWidgetRepository , un HibernateWidgetRepository , un XmlWidgetRepository , un JpaWidgetRepository , etc. qui implémente votre interface.

La règle générale serait d’utiliser un niveau d’abstraction aussi élevé que possible tout en satisfaisant vos exigences. Dans l'exemple de liste que j'ai donné, un référentiel basé sur JPA serait le niveau le plus élevé, car il résume même le cadre ORM.

Vous pouvez ensuite conserver une référence WidgetRepository dans vos objets qui l'utilisent. Code seulement contre cette interface. Ensuite, mettez en place un cadre Injection de dépendance comme Spring , qui injectera une implémentation concrète WidgetRepository au moment de l’exécution, basée sur une configuration XML ou un mécanisme de câblage automatique.