Dependency Injection

Eintrag zuletzt aktualisiert am: 19.11.2020

Dependency Injection (deutsch: Einbringen von Abhängigkeiten) ist ein Entwurfsmuster der objektorientierten Programmierung (OOP), bei dem Abhängigkeit zwischen Objekte erst zur Laufzeit hergestellt werden. Dabei werden die Abhängigkeiten nicht wie in einem herkömmlichen System in einzelnen Klassen, sondern an zentraler Stelle in einem sogenannten "DI Container" (Injektor) festgelegt (Single-Responsibility-Prinzip / Inversion of Control). Der DI-Container ist dafür zuständig, die Abhängigkeiten zur Laufzeit herzustellen.

Dependecy Injection ist eine Kerntechnik für die Entwicklung lose gekoppelter Systeme, bei der die Anwendungsteile erst beim Start der Anwendung zusammengesetzt werden.

Der Begriff DI soll auf Martin Fowler [https://martinfowler.com/articles/injection.html] zurückgehen.

Beispiel: Eine Klasse "Auto" sieht vor, eine Beziehung zur eine Schnitstelle IFahrer zu haben. Per Dependency Injection (DI) wird an zentraler Stelle festgelegt, welche Klasse für die Schnittstelle IFahrer verwendet werden soll. Im Standard könnte man die Klasse MenschlicherFahrer verwenden. Man könnte aber stattdessen das System auch starten mit einer Instanz der Klasse Prüfstand oder der Klasse AutomatisierterFahrer, die beide auch IFahrer implementieren.
Häufiges Anwendungsgebiet für Dependency Injection: Ersetzen von realen Implementierungen durch Mock-Objekte im Rahmen von Unit Tests.

Vorteile der Dependency Injection:

Lose Kopplung / Single-Responsibility-Prinzip
Konfigurierbarkeit (auch zur Betriebszeit)
Zentrale Initialisierung
Abstraktion von konkreten Implementierungen
Testbarkeit

Nachteile der Dependency Injection:

Erhöhter Aufwand
Erhöhte Komplexität
Code unübersichtlicher, schlechter lesbar
Abhängigkeit von Dependency Injection-Framework

Formen der Dependency Injection

• Konstruktor-Injektion
• Property-Injektion
• Methoden-Injektion

Dependency Injection-Frameworks in .NET

Microsoft Unity Container: https://github.com/unitycontainer/unity
Castle Windsor
Autofac
StructureMap

Beispielcode: Dependency Injection ohne Dependency Injection-Container-Framework

In einem Komponentenbasierten Systeme bzw. bei der Nutzung eines Services instanziiert der Client normalerweise den Server/die Komponente/den Service:

class Umwelt
{
Client c = new Client();
c.Vorgang()
}

class Client
{
public void Vorgang()
{
Dienst d = new Dienst();
d.Aktion();
}
}

class Dienst
{
public void Aktion()
{
…
}
}

Der Nachteil dieser Methode ist,
a) dass der Dienst nicht einfach gegen einen anderen ausgetauscht werden kann
b) dass der Client nicht ohne den Dienst getestet werden kann.

Dependency Injection geht davon aus, dass die konkrete Implementierung des Dienstes variabel ist und von der Umwelt an den Client übergeben wird, z.B. im Konstruktor oder durch Übergabe ein ein Property, einen Methodenaufruf. Dabei kann entweder der Typ des Dienstes, direkt eine Instanz des Dienstes oder aber ein Initialisierungsobjekt übergeben werden, das den Dienst beschreibt.

Beispeil: Injektion durch Konstruktor und eine konkrete Instanz

class Umwelt
{
Client c = new Client(new Dienst());
c.Vorgang()
}

class Client
{
Dienst d;

public Client(Dienst Dienst)
{
d = Dienst;
}

public void Vorgang()
{
d.Aktion();
}
}

class Dienst
{
public void Aktion()
{
…
}
}