it-swarm.com.de

Warum brauchen wir Frameworks für die Abhängigkeitsinjektion?

Ich habe mehr über das Inversion of Control-Prinzip und die Abhängigkeitsinjektion als Implementierung gelesen und bin mir ziemlich sicher, dass ich es verstehe.

Es scheint im Grunde zu sagen: "Deklarieren Sie nicht die Instanziierungen Ihrer Klassenmitglieder innerhalb der Klasse". Vielmehr sollten die Instanziierungen über den Konstruktor übergeben und zugewiesen werden. von einer externen Quelle in die Klasse "injiziert".

Wenn es so einfach ist, wie es scheint, warum brauchen wir Frameworks wie Spring oder Guice, die dies mit Anmerkungen implementieren? Vermisse ich hier etwas Grundlegendes? Ich habe wirklich Probleme zu verstehen, wie Dependency Injection Frameworks verwendet werden.

Bearbeiten: Über das mögliche Duplikat glaube ich, dass meine Frage einzigartiger ist, da sie sich auf DI-Frameworks im Allgemeinen bezieht, nicht nur auf Spring. Spring ist nicht nur ein DI-Framework, daher gibt es viele Gründe, warum jemand Spring verwenden möchte, die nicht mit DI zusammenhängen.

43
timsworth

Wir brauchen die Rahmenbedingungen nicht. Es ist durchaus möglich, die Abhängigkeitsinjektion manuell zu implementieren, selbst für ein relativ großes Projekt.

Auf der anderen Seite erleichtert die Verwendung eines Frameworks die Arbeit, insbesondere eines, das auf Anmerkungen oder der automatischen Erkennung von Abhängigkeiten basiert, da dies den Prozess vereinfacht: Wenn ich mich für eine neue Abhängigkeit in einer Klasse entscheide, muss ich nur hinzufügen es an den Konstruktor (oder einen Setter deklarieren) und das Objekt wird injiziert - ich muss keinen Instanziierungscode ändern.

Frameworks enthalten häufig auch andere nützliche Funktionen. Spring enthält beispielsweise ein nützliches Framework für die aspektorientierte Programmierung, einschließlich der deklarativen Transaktionsabgrenzung (was äußerst praktisch ist) und einer Vielzahl von Adapterimplementierungen, die die Integration vieler Bibliotheken von Drittanbietern erleichtern.

26
Jules
  1. Warum brauchen wir überhaupt DI (Dependency Injection)?

    Der DI-Mechanismus trennt die Objektproduktion vom Objektverbrauch. Die Abhängigkeiten, die ein Objekt benötigt, werden von außen transparent geliefert. Der Vorteil des Mechanismus liegt auf der Hand: Sie können jederzeit Abhängigkeiten austauschen, z. Verwenden eines Null-Objekts zu Testzwecken.

  2. Wie wird es gemacht?

    Es gibt verschiedene Möglichkeiten, um das Ziel zu erreichen:

    • Injizieren von Abhängigkeiten über Konstruktorinjektion
    • Injektion über Getter/Setter
    • Schnittstelleninjektion
  3. Benötigen wir DI-Frameworks?

    Nein überhaupt nicht. Sie können einfach alle Instanzen manuell an andere Objekte übergeben. Wenn Sie eine kleine Anwendung haben, ist kein Federbehälter erforderlich.

    Auf der anderen Seite helfen Ihnen Frameworks bei der Verwaltung von Objekten:

    • Sie helfen Ihnen bei der Verkabelung komplexer Objektbeziehungen. Sie müssen keinen Boilerplate-Code schreiben, um Instanzen zu generieren und an die entsprechenden Objekte zu übergeben

    • Sie helfen Ihnen dabei, wann ein Objekt zu steuern: Sie können Instanzen während des Anwendungs-Bootstrappings erstellen, aber in einigen Fällen ist eine verzögerte Erstellung - nur bei Bedarf - besser

    • Sie helfen Ihnen dabei, wie viele Instanzen zu steuern, die erstellt werden: eine pro Anwendungslebensdauer oder eine pro Anforderung (falls Sie Webprogrammierung durchführen)

Wenn Ihr Projekt eine angemessene Größe hat - wenn Sie das Gefühl haben, weniger Boilerplate-Code schreiben zu müssen - ist die Verwendung eines (DI-) Frameworks absolut sinnvoll. Es gibt mehr Vor- als Nachteile.

12
Thomas Junk

Mit dem Frühling ist es meistens eine Frage der Bequemlichkeit.

Wenn Sie die Klasse TopLevel haben, die die Klasse MiddleLevel ist, die die Klasse LowLevel konstruiert, und Sie erkennen, dass Sie einen neuen Konstruktorparameter für LowLevel benötigen, müssen Sie dies tun Fügen Sie es auch zu TopLevel und MiddleLevel hinzu, damit der Wert verfügbar ist, wenn MiddleLevel ein LowLevel erstellt es kann an seinen Konstruktor übergeben werden. Mit spring fügen Sie einfach eine Anmerkung hinzu.

Mit spring ist es auch möglich, die Abhängigkeiten in einer externen Konfigurationsdatei anstelle von XML zu definieren, und dies gibt Ihnen angeblich die Möglichkeit, ein neues System mit einer völlig anderen Verkabelung zu generieren, "ohne Code zu ändern". (IMHO ist dies völlig fehlgeleitet, da sich das Ändern von XML nicht wesentlich vom Ändern von Code unterscheidet und Code normalerweise eine weitaus bessere Fehler- und Typprüfung aufweist als XML.)

Eine andere Sache ist, dass viele Menschen Angst vor Konstrukteuren haben; sie verstehen sie nicht, sie mögen sie nicht, sie würden sie lieber nicht benutzen.

5
Mike Nakis

Vor einigen Jahren schrieb ich in einem Unternehmen, für das ich früher gearbeitet hatte, ein Programm zur Überwachung von Webseiten, Webportlets und sogar bestimmter Datenbanktabellen. Ich wollte, dass es flexibel genug ist, damit der Benutzer angeben kann, welche Monitore mit welchen Parametern (URLs, Anmeldungen, Erfolgskriterien usw.) ausgeführt werden sollen. Also habe ich es geschrieben, um aus einer XML-Datei zu lesen und Java Reflection, um die angegebenen Klassen zu instanziieren und Setter-Methoden zum Festlegen der angegebenen Parameter zu verwenden.

Später fand ich heraus, dass der Frühling dasselbe für Sie tun wird und noch viel mehr.

Also in meinem Fall habe ich das gefunden

  1. Die Verwendung eines Abhängigkeitsinjektionsframeworks macht das Programm flexibler und erleichtert die Angabe seiner Funktionsweise (natürlich innerhalb genau definierter Parameter).

  2. Die Verwendung eines DI-Frameworks eines Drittanbieters verhindert, dass Sie das Rad neu erfinden müssen.

1