Die gut angewendete Abhängigkeitsinversion bietet Flexibilität und Stabilität auf der Ebene der gesamten Architektur Ihrer Anwendung. Dadurch kann sich Ihre Anwendung sicherer und stabiler entwickeln.
Traditionelle Schichtarchitektur
Traditionell hing eine Benutzeroberfläche mit geschichteter Architektur von der Geschäftsschicht ab, und dies hing wiederum von der Datenzugriffsschicht ab.
Sie müssen die Ebene, das Paket oder die Bibliothek verstehen. Mal sehen, wie der Code wäre.
Wir hätten eine Bibliothek oder ein Paket für die Datenzugriffsschicht.
// DataAccessLayer.dll
public class ProductDAO {
}
Und eine andere Geschäftslogik der Bibliotheks- oder Paketschicht, die von der Datenzugriffsschicht abhängt.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private ProductDAO productDAO;
}
Schichtarchitektur mit Abhängigkeitsinversion
Die Abhängigkeitsinversion zeigt Folgendes an:
High-Level-Module sollten nicht von Low-Level-Modulen abhängen. Beides sollte von Abstraktionen abhängen.
Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.
Was sind die High-Level-Module und Low-Level-Module? Bei Modulen wie Bibliotheken oder Paketen handelt es sich bei Modulen auf hoher Ebene um Module, die traditionell Abhängigkeiten aufweisen und von denen sie auf niedriger Ebene abhängen.
Mit anderen Worten, auf hoher Ebene des Moduls wird die Aktion aufgerufen und auf niedriger Ebene wird die Aktion ausgeführt.
Eine vernünftige Schlussfolgerung aus diesem Prinzip ist, dass es keine Abhängigkeit zwischen Konkretionen geben sollte, sondern eine Abhängigkeit von einer Abstraktion. Aber nach dem Ansatz, den wir verfolgen, können wir die Abhängigkeit von Investitionen falsch anwenden, aber eine Abstraktion.
Stellen Sie sich vor, wir passen unseren Code wie folgt an:
Wir hätten eine Bibliothek oder ein Paket für die Datenzugriffsschicht, die die Abstraktion definieren.
// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{
}
Und eine andere Geschäftslogik der Bibliotheks- oder Paketschicht, die von der Datenzugriffsschicht abhängt.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private IProductDAO productDAO;
}
Obwohl wir von einer Abstraktionsabhängigkeit abhängig sind, bleibt die Abhängigkeit zwischen Geschäft und Datenzugriff gleich.
Um eine Abhängigkeitsinversion zu erhalten, muss die Persistenzschnittstelle in dem Modul oder Paket definiert werden, in dem sich diese Logik oder Domäne auf hoher Ebene befindet, und nicht im Modul auf niedriger Ebene.
Definieren Sie zunächst, was die Domänenschicht ist, und die Abstraktion ihrer Kommunikation wird als Persistenz definiert.
// Domain.dll
public interface IProductRepository;
using DataAccessLayer;
public class ProductBO {
private IProductRepository productRepository;
}
Nachdem die Persistenzschicht von der Domäne abhängt, können Sie jetzt invertieren, wenn eine Abhängigkeit definiert ist.
// Persistence.dll
public class ProductDAO : IProductRepository{
}
(Quelle: xurxodev.com )
Das Prinzip vertiefen
Es ist wichtig, das Konzept gut zu verarbeiten und den Zweck und die Vorteile zu vertiefen. Wenn wir mechanisch bleiben und das typische Fall-Repository kennenlernen, können wir nicht identifizieren, wo wir das Prinzip der Abhängigkeit anwenden können.
Aber warum invertieren wir eine Abhängigkeit? Was ist das Hauptziel über spezifische Beispiele hinaus?
Dies ermöglicht üblicherweise, dass sich die stabilsten Dinge, die nicht von weniger stabilen Dingen abhängig sind, häufiger ändern.
Es ist einfacher, den Persistenztyp zu ändern, entweder die Datenbank oder die Technologie, um auf dieselbe Datenbank zuzugreifen, als die Domänenlogik oder Aktionen, die für die Kommunikation mit der Persistenz ausgelegt sind. Aus diesem Grund ist die Abhängigkeit umgekehrt, da es einfacher ist, die Persistenz zu ändern, wenn diese Änderung auftritt. Auf diese Weise müssen wir die Domain nicht ändern. Die Domänenschicht ist die stabilste von allen, weshalb sie von nichts abhängen sollte.
Es gibt jedoch nicht nur dieses Repository-Beispiel. Es gibt viele Szenarien, in denen dieses Prinzip gilt, und es gibt Architekturen, die auf diesem Prinzip basieren.
Architekturen
Es gibt Architekturen, bei denen die Abhängigkeitsinversion der Schlüssel zu ihrer Definition ist. In allen Domänen ist es das Wichtigste und es sind Abstraktionen, die angeben, dass das Kommunikationsprotokoll zwischen der Domäne und den übrigen Paketen oder Bibliotheken definiert ist.
Saubere Architektur
In der sauberen Architektur befindet sich die Domäne in der Mitte. Wenn Sie in Richtung der Pfeile schauen, die die Abhängigkeit anzeigen, ist klar, welche Ebenen am wichtigsten und stabilsten sind. Die äußeren Schichten gelten als instabile Werkzeuge. Vermeiden Sie daher, von ihnen abhängig zu sein.
(Quelle: 8thlight.com )
Sechseckige Architektur
Genauso verhält es sich mit der hexagonalen Architektur, bei der sich die Domäne ebenfalls im zentralen Teil befindet und Ports Abstraktionen der Kommunikation vom Domino nach außen sind. Auch hier ist offensichtlich, dass die Domäne am stabilsten ist und die traditionelle Abhängigkeit invertiert ist.
