Dépendance circulaire de la logique métier et de la couche d'accès aux données

Question

Je travaille sur un projet MVC où je suis l'architecture en couches. Après avoir lu et fait des recherches sur le web, j'ai compris que l'utilisation de couches séparées est une approche optimale. Donc, mes couches sont:

• couche de présentation a: Contrôleurs, Vues
• Business Layer: projet de bibliothèque de classes séparées (Comprend les modèles de domaine (représentant les entités de table), les services de logique métier, dossier séparé pour ViewModels)
• données couche d'accès: A des appels à la base de données (instructions SQL, connexions)

maintenant, le problème se pose:

BLL appelle à la couche d'accès aux données:

public PartnerOperation(IDataAccess dataRepository) 
    { 
     _dataAccess = dataRepository; 
    } 

    public void InsertRequest(PartnerRequestModel partnerRequestModel) 
    { 
     _dataAccess.InsertIntoDB(partnerRequestModel); //Domain object passed to DLL method 
    } 

Maintenant, mon BLL dépend sur la couche d'accès aux données qui est en fonction de BLL parce que les objets de domaine sont à l'intérieur BLL. Donc, les deux ont des références les uns aux autres. Je suis rigoureusement à la recherche pendant quelques semaines, mais je n'ai pas trouvé de solution.

J'ai déjà traversé Business Logic Layer and Data Access layer: circular dependency mais cela ne résout pas complètement mon problème.

Certains sites Web prennent en charge l'architecture de couche, une certaine approche d'oignon revendiquée est meilleure. Par exemple: this article affirme que toute cette approche (Controller -> BLL -> DLL) n'est pas optimale.

1. Comment puis-je surmonter la dépendance circulaire?
2. Mon approche pour la construction de cette application Web est-elle valide?

Answer 1

Vous pouvez utiliser une architecture Onion, également connu sous le nom de Hexagonal ou Ports & Adaptateurs (variations légèrement différentes sur la même chose). Avec cette architecture, votre couche de persistance (données) fait référence à votre couche de domaine, de sorte que vos référentiels, etc., peuvent renvoyer des entités de domaine. Pour utiliser vos référentiels de votre couche de domaine, vous devez ensuite placer les interfaces de vos référentiels dans votre couche de domaine et les connecter aux implémentations (dans la couche de persistance) à l'aide d'un conteneur IoC.

Modifier

Il ne semble pas que si vous faites DDD de votre terminologie et l'exemple de code que vous avez fourni, je devine que vous avez inclus la balise DDD à cause du terme référentiel, donc je vais continuer en utilisant non terminologique DDD, n-tier et en couches.

Vous allez regarder une pile d'appels à peu près la même chose. Ce sera Controller -> Service -> Repository. Idéalement, vous devez référencer une «unité de travail» dans votre service et ne pas référencer directement les dépôts. La seule différence est les références de projet, au lieu de la référence BLL de la DLL, ce sera l'inverse. Votre contrôleur appellera toujours le code dans un service de la BLL. C'est juste que votre service BLL n'aura pas de référence à la DLL. Donc, pour contourner cela, vous mettez les interfaces à partir des dépôts DLL dans la BLL et les câbler en utilisant un conteneur IoC comme Ninject ou Castle Windsor. Vous devrez peut-être examiner quelques autres sujets comme Dependency Inject (DI) (passant les dépendances à travers le constructeur), Inversion of Control (IoC) (un grand mappage global de l'instanciation automatique des types concrets d'interfaces configurés) et pour un objectif à plus long terme peut-être la conception basée sur le domaine (DDD) pour donner un sens à certains des avantages que vous obtiendriez de l'utilisation d'une architecture Onion.

Answer 2

Les objets métier ne sont pas identiques aux objets de données. Vos objets métier doivent contenir une connexion d'entreprise pendant que les objets de données sont créés pour la persistance. Si vous utilisez une architecture en couches simple, vous pouvez mapper des objets métier aux objets de données lorsque vous devez envoyer des données entre des couches. Vous pouvez mapper en écrivant le code de mappage ou en utilisant des outils comme Automapper.

Le problème global ici est que vous conservez votre modèle de vue, ce qui rend la couche logique métier redondante. Si vous choisissez ce chemin, vous pouvez définir vos entités dans le DAL et les utiliser dans la BLL, car elles ne contiennent que les données. Lorsque vous commencez à vouloir séparer votre modèle de domaine de votre modèle de persistance, ce sera une autre histoire et vous pourriez en venir à DDD, mais ce que vous planifiez n'est pas DDD. Si vous voulez un échantillon de base sur MVC avec une sorte de DDD, this is what I was able to find quickly, je suis sûr qu'il y a plus d'échantillons disponibles. L'article donne des exemples avec MVC et EF et explique quelques notions de base derrière DDD dans des termes raisonnables. J'espère que cela peut être un bon point de départ pour vous. Il y a aussi quelques cours sur Pluralsight qui pourraient vous intéresser.

Answer 3

Une dépendance circulaire peut indiquer une mauvaise conception, en particulier un couplage. Si A dépend de B et B dépend de A, il vous manque probablement une troisième entité C. Alors que A dépend de B et que les deux ont des dépendances sur C. L'architecture multicouche ne doit pas impliquer une solution à trois couches. N'hésitez pas à diviser votre couche de gestion en deux assemblages si nécessaire.