Conception de la couche d'accès aux données

Question

Je suis confrontée à un problème de conception concernant la conception de ma couche d'accès aux données. Comme nous le savons tous, dans sa définition la plus basique, le DAL signifie la couche qui est responsable de la communication avec certains référentiels de données (bien sûr, je ne parle pas du modèle Repository), habituellement une base de données. Maintenant, c'est là que la capture est. Certains de nos objets de gestion devraient extraire leurs données de la base de données et certains recevraient leurs données d'autres sources, par exemple des services Web. Quelques-uns de nos membres de l'équipe ont suggéré que les BO devraient être assez intelligents pour savoir s'ils doivent appeler un DAL (qui ne sait que parler à la base de données) ou appeler le service Web requis. D'autres ont suggéré que cela pourrait ne pas être une solution optimale, suggérant que tout devrait passer par le DAL, où il contiendrait disons des adaptateurs, ou peu importe, pour chaque méthode de récupération de données.

Comment concevez-vous un système avec de tels besoins d'accès aux données? Est-ce que l'une des solutions suggérées pourrait être assez bonne pour le long terme (la deuxième pourrait prendre plus de temps à se développer) ou devons-nous adopter une approche totalement différente? Peut-être il y a un modèle de conception qui convient à ce genre de question ...

Merci, Avi Shilon

Answer 1

Je recommande fortement la deuxième approche. La logique métier ne doit rien savoir de la source des données.

Quand il ne sait pas, en plus des avantages habituels (plus facile maintenabilité en raison de l'isolement et la conception plus propre), vous avez également la flexibilité (en fonction de la façon dont votre DAL a été conçu) pour:

• En tant que conditions minimales requises, récupérez des données provenant de diverses sources de données

• Récupérez des données d'un ensemble de sources de données prioritaires pour effectuer un basculement.

  E.g. vous obtenez les dernières cotations du service de devis en temps réel de Reuters, mais lorsque cela se décompose en raison de problèmes de WAN, vous retombez sur un autre service, ou des prix plus anciens mis en cache dans la base de données.

  De toute évidence, les sources de données sont classées dans la priorité de qualité non croissante et de fiabilité non décroissante.

• Récupérer des données à partir d'un ensemble hiérarchisé de sources de données pour réaliser la mise en cache

  Par ex récupérer un prix à partir d'un cache local, s'il est manquant, récupérer à partir d'une base de données locale, s'il est manquant, demander au service du fournisseur.

Aussi, juste pour donner un exemple de chair et d'os de maintenabilité plus facile, si des changements de source vos données à partir d'un temps réel interrogés service fournisseur à base de données interne de copie d'or rempli par un flux de poussée du vendeur, vous auriez seulement besoin de changer le DAO au lieu de chacun de la multitude de BOs qui ont besoin des données. Plus facile à changer, et plus sûr de tester et déployer le changement.