Heim  >  Artikel  >  Backend-Entwicklung  >  Analyse der logischen Schichtarchitektur von .NET

Analyse der logischen Schichtarchitektur von .NET

怪我咯
怪我咯Original
2017-04-05 13:31:351754Durchsuche

1. Grundwissensvorbereitung:

1. Prinzipien der Schichten:

(1) Jede Schicht beginnt mit Schnittstelle wird von der oberen Ebene zum Aufrufen verwendet. (2) Die obere Schicht kann nur die untere Schicht aufrufen.
(3) Abhängigkeiten werden in zwei Typen unterteilt: lockere Interaktion und strikte Interaktion.

2. Klassifizierung der Geschäftslogik:

(1) Anwendungslogik.

(2) Domänenlogik.

 3. Angenommene Schichten:

  (1) Präsentationsschicht (Benutzeroberflächenschicht): domänenunabhängig.

(2) Serviceschicht (Anwendungsschicht): Anwendungslogik.
(3) Geschäftslogikschicht (Domänenschicht): Domänenlogik.
(4) Gemeinsam genutzte Ebene: Stellt gemeinsamen Code bereit.
(5) Implementierungsschicht: Bietet Schnittstellenimplementierung.

4. Vereinbarung:

(1) Die Domänenschicht verwendet standardmäßig das Domänenmodell

(2) Die Datenzugriffsschicht benötigt um standardmäßig auf die Domäne zu verweisen Modell

2. Schichtarchitektur

Die drei Grundebenen der Schichtarchitektur sind: Präsentationsschicht, Geschäftslogikschicht und Datenzugriffsschicht. Wenn die Geschäftslogikschicht entsprechend der Klassifizierung der Geschäftslogik in Serviceschicht und Domänenschicht zerlegt wird, werden die drei Schichten in vier Schichten erweitert: Präsentationsschicht, Serviceschicht, Domänenschicht und Datenzugriffsschicht. Die Datenzugriffsschicht muss im Allgemeinen das Domänenmodell verstehen, wodurch wechselseitige Abhängigkeiten zwischen Schichten entstehen:

1. Platzieren Sie das Domänenmodell in der gemeinsam genutzten Ebene:

Bewertung: PetShop verwendet dieses Modell, weist jedoch viele Mängel auf: Die Geschäftslogikschicht verdient ihren Namen nicht und das Domänenmodell ist eigentlich ein Datenmodell , das Abhängigkeiten zwischen den Ebenen aufrechterhält und weitere Abhängigkeiten einführt, ist das offensichtliche datengesteuerte

Denken nicht domänenorientiert.

2. Definieren Sie die Datenzugriffsschnittstelle in der Geschäftslogikschicht:

Bewertung: NopCommerce übernimmt dieses Modell, auch wenn es ist getrennt Die Serviceschicht wurde entfernt und die Benennungsmethode der Ressourcenbibliothek übernommen. NopCommerce ist jedoch keine DDD-Schichtarchitektur, sondern eine gewöhnliche dreistufige Architektur, die die Prinzipien der Domänenmodell- und Schnittstellentrennung übernimmt. Nachteile: Abgesehen von der Datenimmobilie sind keine weiteren spezifischen technischen Abhängigkeiten von der Geschäftslogikschicht getrennt.

3. DDD-Schichtung:

DDD-Schichtung unterteilt die Geschäftslogikschicht klar in Anwendungsschicht (Dienstschicht) und Domänenschicht. Gleichzeitig werden die spezifischen technischen Implementierungsteile des Datenzugriffs und anderer Schnittstellen in der Infrastrukturschicht vereinheitlicht.

1. Ursprüngliche DDD-Schichtung:

Bewertung: Der Vorteil besteht darin, dass die spezifische Technologieimplementierung von der Domäne getrennt ist, und die Infrastrukturschicht Erhöhter Wiederverwendungswert. Der Nachteil besteht darin, dass das Konzept der gemeinsamen Nutzung und Implementierung nicht zur Unterteilung der Infrastrukturschicht verwendet wird, was zu umgekehrten Abhängigkeiten bei der Implementierung von Warehousing in der Infrastrukturschicht führt, obwohl dies keine Auswirkungen auf eine Einzelprojektlösung hat (nur der

Namespace Ebene formale Abhängigkeit), aber in einer .NET-Multiprojektlösung kann die Warehousing-Implementierung nur durch Schnittstellentrennung in eine ähnliche Datenzugriffsschicht aufgeteilt werden.

 2. Verbesserte DDD-Schichtung:

Bewertung: Die Infrastrukturschicht weist die Merkmale sowohl der Freigabeschicht als auch der Implementierungsschicht auf . Der Vorteil besteht darin, dass die Domäne letztendlich formal den Kern darstellt, und es beseitigt auch die Peinlichkeit, bei der Implementierung von Warehousing in der Infrastrukturschicht nicht auf das Domänenmodell verweisen zu können. Der Nachteil besteht darin, dass es auch keinen Unterschied zwischen den Konzepten der gemeinsamen Nutzung und der Implementierung gibt .

3. Die neueste DDD-Schichtung:

Bewertung: Der Vorteil ist, dass dies wirklich domänenzentriert ist, egal was passiert Eine erneute Anpassung in der Serviceschicht ist nicht erforderlich, da die Infrastrukturschicht nicht auf die Domänenschicht verweisen kann. Verwenden Sie das Prinzip der Abhängigkeitsumkehr, um die Abhängigkeiten jeder Schicht von bestimmten Technologien vollständig umzukehren. Nachteile: Die Abhängigkeitsinvertierung wird in einer Einzelprojektlösung zu häufig angewendet, führt jedoch in einer .NET-Mehrprojektlösung zu bidirektionalen Abhängigkeiten in Form von Namespaces. Als Implementierungsschicht hat die Infrastrukturschicht grundsätzlich keinen Wiederverwendungswert. Ein besserer Ansatz besteht darin, die Positionen der Benutzeroberflächenschicht und der Infrastrukturschicht im Diagramm zu vertauschen.

Sie können bei Bedarf entsprechende gemeinsame Ebenen zum obigen Bild hinzufügen.

IV. Architekturtrends:

(1) Da die Geschäftslogik der Kern ist, achten Sie mehr auf die Geschäftslogik.
(2) Teilen Sie die spezifischen Abhängigkeiten der Geschäftslogikschicht für eine einheitliche Verwaltung in eine Ebene auf.
(3) Achten Sie mehr auf die Reduzierung von Abhängigkeiten innerhalb von Lösungen als auf die Wiederverwendung von Code zwischen Lösungen.
(4) Die Trennung der Freigabeschicht und der Implementierungsschicht wird zunehmend reflektiert. Zum Beispiel Zwiebelarchitektur.

Das obige ist der detaillierte Inhalt vonAnalyse der logischen Schichtarchitektur von .NET. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn