Analyse de l'architecture en couches logiques .NET

1. Préparation des connaissances de base :

1. Principes des couches :

(1) Chaque couche commence par Interface est utilisée par la couche supérieure pour appeler. (2) La couche supérieure ne peut appeler que la couche inférieure.
(3) Les dépendances sont divisées en deux types : l'interaction lâche et l'interaction stricte.

2. Classification de la logique métier :

(1) Logique applicative.

(2) Logique de domaine.

　3.Couches adoptées :

　 (1) Couche de présentation (couche d'interface utilisateur) : indépendante du domaine.

(2) Couche de service (couche d'application) : logique d'application.
(3) Couche de logique métier (couche de domaine) : logique de domaine.
(4) Couche partagée : fournit un code commun.
(5) Couche d'implémentation : fournit l'implémentation de l'interface.

4. Accord :

(1) La couche de domaine est par défaut le modèle de domaine

(2) La couche d'accès aux données a besoin pour référencer le domaine par défaut Modèle

2. Architecture en couches

Les trois niveaux de base de l'architecture en couches sont : la couche de présentation, la couche de logique métier et la couche d'accès aux données. Si la couche de logique métier est décomposée en couche de service et couche de domaine selon la classification de la logique métier, les trois couches sont développées en quatre couches : couche de présentation, couche de service, couche de domaine et couche d'accès aux données. La couche d'accès aux données doit généralement comprendre le modèle de domaine, ce qui créera des dépendances bidirectionnelles entre les couches. Nous avons généralement les deux solutions suivantes :

1. Placer le modèle de domaine dans la couche partagée :

Évaluation : PetShop utilise ce modèle, mais il présente de nombreux défauts : la couche de logique métier n'est pas digne de son nom, et le modèle de domaine est en réalité un modèle de données , qui maintient les dépendances inter-couches et introduit plus de dépendances, une réflexion évidente

axée sur les données , et non axée sur le domaine.

2. Définir l'interface d'accès aux données dans la couche de logique métier :

Évaluation : NopCommerce adopte ce modèle, même s'il est séparé La couche de service a été supprimée et la méthode de dénomination des bibliothèques de ressources a été adoptée. Cependant, NopCommerce n'est pas une architecture en couches DDD, mais une architecture ordinaire à trois niveaux qui adopte les principes du modèle de domaine et de la séparation des interfaces. Inconvénients : hormis l'immobilier de données, aucune autre dépendance technique spécifique n'est séparée de la couche de logique métier.

3. Superposition DDD :

La superposition DDD divise clairement la couche de logique métier en deux parties : la couche application (couche de service) et la couche de domaine. Dans le même temps, les parties spécifiques de mise en œuvre technique de l’accès aux données et d’autres interfaces sont unifiées dans la couche infrastructure.

1. Superposition DDD originale :

Évaluation : L'avantage est que la mise en œuvre de la technologie spécifique est séparée du domaine, et la couche infrastructure Augmentation de la valeur de réutilisation. L'inconvénient est que le concept de partage et de mise en œuvre n'est pas utilisé pour subdiviser la couche infrastructure, ce qui entraîne des dépendances inverses lors de la mise en œuvre de l'entreposage dans la couche infrastructure, bien que cela n'ait aucun impact dans une solution à projet unique (uniquement l'

espace de noms niveau de dépendance formelle), mais dans une solution multi-projets .NET, l'implémentation de l'entrepôt ne peut être séparée en une couche d'accès aux données similaire que via la séparation des interfaces.

　2. Superposition DDD améliorée :

Évaluation : La couche d'infrastructure présente les caractéristiques à la fois de la couche de partage et de la couche de mise en œuvre. . L'avantage est que le domaine est finalement formellement le noyau et cela résout également l'embarras de ne pas pouvoir référencer le modèle de domaine lors de l'implémentation de l'entreposage dans la couche infrastructure. L'inconvénient est qu'il n'y a pas non plus de distinction entre les concepts de partage et d'implémentation. .

3. La dernière superposition DDD :

Évaluation : L'avantage est qu'elle est véritablement centrée sur le domaine. besoin de s'adapter à nouveau dans la couche de service car la couche d'infrastructure ne peut pas référencer la couche de domaine. Utilisez le principe d'inversion de dépendances pour inverser complètement les dépendances de chaque couche sur des technologies spécifiques. Inconvénients : l'inversion des dépendances est trop appliquée. Cela ne pose également aucun problème dans une solution à projet unique, mais dans une solution multi-projets .NET, cela conduira à des dépendances bidirectionnelles sous la forme d'espaces de noms. En tant que couche de mise en œuvre, la couche d'infrastructure n'a fondamentalement aucune valeur de réutilisation. Une meilleure approche consiste à permuter les positions de la couche d'interface utilisateur et de la couche d'infrastructure dans le diagramme.

Vous pouvez envisager d'ajouter des calques partagés appropriés à l'image ci-dessus si nécessaire.

IV. Tendances architecturales :

(1) Prenez la logique métier comme noyau et accordez plus d'attention à la logique métier.
(2) Divisez les dépendances spécifiques de la couche de logique métier en un seul niveau pour une gestion unifiée.
(3) Accordez plus d'attention à la réduction des dépendances au sein des solutions plutôt qu'à la réutilisation du code entre les solutions.
(4) La séparation de la couche de partage et de la couche de mise en œuvre sera de plus en plus reflétée. Par exemple, l'architecture de l'oignon.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!