Looking for .net Keywords? Try Ask4Keywords

.NET FrameworkAbhängigkeitsspritze


Bemerkungen

Probleme, die durch Abhängigkeitseinspritzung gelöst werden

Wenn wir keine Abhängigkeitsinjektion verwendet haben, könnte die Greeter Klasse eher wie Greeter aussehen:

public class ControlFreakGreeter
{
    public void Greet()
    {
        var greetingProvider = new SqlGreetingProvider(
            ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString);
        var greeting = greetingProvider.GetGreeting();
        Console.WriteLine(greeting);
    }
}

Es ist ein "Kontrollfreak", weil er das Erstellen der Klasse, die die Begrüßung bereitstellt, steuert, wo die SQL-Verbindungszeichenfolge herkommt und die Ausgabe steuert.

Mit der Abhängigkeitseinspritzung gibt die Greeter Klasse diese Verantwortlichkeiten zugunsten einer einzigen Verantwortung auf und schreibt eine Begrüßung.

Das Prinzip der Abhängigkeitsinversion legt nahe, dass Klassen von Abstraktionen (wie Schnittstellen) und nicht von anderen konkreten Klassen abhängen sollten. Direkte Abhängigkeiten (Kopplung) zwischen Klassen können die Wartung zunehmend erschweren. Abhängig von Abstraktionen kann diese Kopplung reduzieren.

Abhängigkeitsinjektion hilft uns, diese Abhängigkeitsinversion zu erreichen, weil sie dazu führt, dass Klassen geschrieben werden, die von Abstraktionen abhängen. Die Greeter Klasse "kennt" die Implementierungsdetails von IGreetingProvider und IGreetingWriter . Es weiß nur, dass die eingefügten Abhängigkeiten diese Schnittstellen implementieren. Das heißt, Änderungen an den konkreten Klassen, die IGreetingProvider und IGreetingWriter implementieren, IGreetingWriter sich nicht auf Greeter . Sie werden auch nicht durch ganz andere Implementierungen ersetzt. Nur Änderungen an den Schnittstellen werden vorgenommen. Greeter ist entkoppelt.

ControlFreakGreeter nicht richtig durchführen. Wir möchten eine kleine Code-Einheit testen, stattdessen würde unser Test das Herstellen einer Verbindung zu SQL und das Ausführen einer gespeicherten Prozedur umfassen. Dazu gehört auch das Testen der Konsolenausgabe. Da ControlFreakGreeter so viel tut, ist es nicht möglich, es isoliert von anderen Klassen zu testen.

Greeter sich leicht als Komponententest testen, da gemockte Implementierungen seiner Abhängigkeiten Greeter können, die einfacher auszuführen und zu überprüfen sind, als eine gespeicherte Prozedur aufzurufen oder die Ausgabe der Konsole zu lesen. Es ist keine Verbindungszeichenfolge in app.config erforderlich.

Die konkreten Implementierungen von IGreetingProvider und IGreetingWriter möglicherweise komplexer. Sie könnten wiederum ihre eigenen Abhängigkeiten haben, die in sie hineingelegt werden. (Zum Beispiel würden wir die SQL-Verbindungszeichenfolge in SqlGreetingProvider .) SqlGreetingProvider Komplexität wird jedoch von anderen Klassen "verborgen", die nur von den Schnittstellen abhängen. Das macht es einfacher, eine Klasse zu ändern, ohne einen "Ripple-Effekt", der die entsprechenden Änderungen an anderen Klassen erfordert.

Abhängigkeitsspritze Verwandte Beispiele