Meilleure pratique pour le modèle DAO?

Question

J'ai vu beaucoup de codes utiliser un modèle de service-dao, je ne connais pas l'origine de ce modèle. Il force le service d'appel de la couche avant, puis délègue une partie de la tâche de service à dao.

Je veux demander:

1. Est-ce que la couche DAO ne tâche purement liées à l'accès des données? Qu'en est-il des choses comme l'encapsulation d'exception?
2. Y at-il un autre modèle peut être utilisé pour remplacer cela ou mieux que cela?
3. Je pense que les modèles de domaine pojo et les scripts de transaction font que le problème même simple est devenu compliqué, est-il possible d'éliminer complètement la couche dao?

Answer 1

Idéalement, votre couche DAO «élimine» l'accès à certains systèmes de stockage de données (base de données, système de fichiers, annuaire LDAP, ...). Donc, dans ce sens, il est utilisé uniquement pour les tâches liées à l'accès aux données. Cependant, vous pouvez également avoir une couche DAO qui accède à un service Web ou à un autre composant externe à votre application. C'est le point clé, il donne accès à un composant externe.

L'idée principale est qu'il n'y a pas de détails d'implémentation de votre couche DAO qui échappent aux couches supérieures (isolation). Un bon point de départ pour penser à ceci est: que devrais-je faire si je prévois de remplacer le composant (une base de données par exemple) auquel ma couche DAO donne accès? Par exemple, vous avez des données dans des fichiers XML et vous prévoyez de migrer les données vers une base de données. Supposons que vous ayez toutes sortes d'exceptions liées au langage XML qui échappent à votre couche DAO. Il devient alors assez difficile de migrer votre couche XML vers une couche de base de données. Cependant, si vous avez encapsulé tous les détails d'implémentation de votre couche DAO, cela deviendra beaucoup plus facile. En fin de compte, il s'agit de la maintenabilité de votre code. Moins vous avez de dépendances sur les détails de mise en œuvre d'une couche spécifique (services, DAO, ...), mieux votre code est maintenable.

Answer 2

L'objectif principal d'une telle couche est de fournir une abstraction de la partie arrière de la persistance. cependant, la plupart du temps, en raison de spécificités de back-end de persistance, le masquage total n'est pas possible; Un exemple typique est la gestion des requêtes. Pour interroger une base de données en utilisant Hibernate, vous allez écrire un type de code de requête (en utilisant HQL, query API, ...) et un paradigme totalement différent lorsque vous utilisez JCR, un BigTable ou autre chose. En conséquence, la plupart du temps, ce modèle échoue. Outre le problème plus ennuyeux de DAO/DTO, il y a aussi le problème plus ennuyeux. Vous êtes ensuite poussé vers l'avant pour écrire une première classe contenant vos données, puis une seconde copie des données de votre premier sans aucune valeur ajoutée juste pour l'isolation des couches.

Il y a cependant du travail qui a été fait dans ce domaine. Pour un micro-framework que j'ai démarré et implémenté pour google-app-engine, j'ai créé un little list de frameworks dao facilitant ce code plutôt banal. Je prévois, à l'avenir, d'être en mesure d'offrir une transparence totale grâce à la définition de service gaedo, mais ce n'est qu'un espoir ;-) (et ne vous intéresse pas, je suppose).

Answer 3

L'accès aux données varie en fonction de la source des données. L'accès au stockage persistant, par exemple à une base de données, varie considérablement en fonction du type de stockage (bases de données relationnelles, bases de données orientées objet, fichiers plats, etc.) et de l'implémentation du fournisseur.Utilisez un objet DAO (Data Access Object) pour extraire et encapsuler tous les accès à la source de données. Le DAO gère la connexion avec la source de données pour obtenir et stocker des données.

Le DAO implémente le mécanisme d'accès requis pour travailler avec la source de données. La source de données peut être un magasin persistant comme un SGBDR, un service externe comme un échange B2B, un référentiel comme une base de données LDAP ou un service métier accédé via le protocole IIOP Internet Inter-ORB ou des sockets de bas niveau. Le composant métier qui s'appuie sur DAO utilise l'interface plus simple exposée par le DAO pour ses clients. Le DAO masque complètement les détails d'implémentation de la source de données de ses clients. Étant donné que l'interface exposée par le DAO aux clients ne change pas lorsque l'implémentation de source de données sous-jacente change, ce modèle permet au DAO de s'adapter à différents schémas de stockage sans affecter ses clients ou composants métier. Essentiellement, le DAO agit comme un adaptateur entre le composant et la source de données.