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

42

Ich habe mehr über das Inversion-of-Control-Prinzip und Dependency-Injection als dessen Implementierung gelesen und bin mir ziemlich sicher, dass ich es verstehe.

Es scheint im Grunde genommen zu heißen, dass Sie Ihre Klassenmitglieder nicht als Instanziierungen innerhalb der Klasse deklarieren. Vielmehr sollten die Instantiierungen über den Konstruktor übergeben und zugewiesen werden. "injiziert" in die Klasse von einer externen Quelle.

Wenn es so einfach ist, wie es scheint, warum brauchen wir Frameworks wie spring oder guice, die dies mit Anmerkungen implementieren? Fehlt mir hier etwas Grundsätzliches? Ich habe wirklich Probleme zu verstehen, was die Verwendung von Dependency Injection-Frameworks ist.

Bearbeiten: Über das mögliche Duplikat, ich glaube, meine Frage ist einzigartiger, da es sich um DI-Frameworks im Allgemeinen handelt, nicht nur um Spring. Spring ist nicht nur ein DI-Framework, daher gibt es viele Gründe, warum jemand Spring verwenden möchte, der nicht mit DI verwandt ist.

timsworth
quelle
11
Sie sind nützlich, um Fehler in die Laufzeit zu verschieben, anstatt die Kompilierungszeit zu überschreiten.
Den
1
@den Warum sollten wir das machen wollen? Das scheint nicht schnell zu scheitern
DIESER BENUTZER BRAUCHT HILFE

Antworten:

26

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

Auf der anderen Seite erleichtert die Verwendung eines Frameworks, insbesondere von Annotationen oder der automatischen Erkennung von Abhängigkeiten, den Prozess: Wenn ich entscheide, dass ich eine neue Abhängigkeit in einer Klasse benötige, muss ich nur noch etwas hinzufügen es an den Konstruktor (oder deklarieren Sie einen Setter) und das Objekt wird injiziert - ich muss keinen Instanziierungscode ändern.

Frameworks enthalten häufig auch andere nützliche Funktionen. Spring enthält zum Beispiel 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.

Jules
quelle
8
Den Nagel auf den Kopf treffen. Wir nicht brauchen sie. Sie erleichtern nur das Leben für große Projekte. Ehrlich gesagt finde ich, dass Frameworks lästiger sind, als sie für kleinere Projekte wert sind. Ich würde OP ermutigen, Dependency Injection nicht mit den Frameworks zu verwechseln, die es unterstützen.
RubberDuck
1
gut gesagt. Und warum das Rad neu erfinden, wenn jemand anderes schon ein schönes und rundes gemacht hat?
Jwenting
Genau das. Außer dass ich keinen Instantiierungscode ändern muss - natürlich gibt es keinen Instantiierungscode ;-)
Mathieu Guindon
Es sieht so aus, als ob Ihre DI-Bibliotheken scheiße wären. Gute können erraten, dass die Klasse mithilfe von Reflexion instanziiert.
Florian Margaine
2
Jeder, der Reflection für die Laufzeitverarbeitung verwendet, macht es falsch. Reflexion ist eine dieser Technologien, die, nur weil Sie etwas tun können, nicht bedeutet, dass Sie sollten.
gbjbaanb
12
  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 Abhängigkeiten jederzeit austauschen, z. B. mit einem Null-Objekt zu Testzwecken.

  2. Wie wird es gemacht?

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

    • Injizieren von Abhängigkeiten über Konstruktorinjektion
    • Einspritzung über Getter / Setter
    • Interface Injection
  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 beim Verwalten 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 bei der Kontrolle, wann ein Objekt erstellt wird: Sie können Instanzen während des Bootstrappens von Anwendungen erstellen, aber in einigen Fällen ist eine verzögerte Erstellung - nur bei Bedarf - besser

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

Wenn Ihr Projekt eine angemessene Größe hat - wenn Sie das Gefühl haben, weniger Code für Boilerplates schreiben zu müssen - ist es absolut sinnvoll, ein (DI-) Framework zu verwenden. Es gibt mehr Vor- als Nachteile.

Thomas Junk
quelle
2
Sie können DI-Bibliotheken verwenden, ohne ein Framework zu verwenden.
Florian Margaine
5

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

Wenn Sie Klasse haben , TopLeveldie sind Konstrukte Klasse , MiddleLeveldie Klasse konstruiert LowLevel, und Sie erkennen , benötigen Sie einen neuen Konstruktor Parameter auf LowLevel, man muss auch hinzufügen , um es zu TopLevel, und MiddleLevel, einfach so , dass , wenn es Zeit für MiddleLeveleinen konstruieren , um LowLevelden Wert zur Verfügung steht damit es an seinen Konstruktor übergeben werden kann. 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, weil das Ändern von XML nicht viel anders ist als das Ändern von Code, und tatsächlich hat Code normalerweise eine weitaus bessere Fehlerprüfung und Typprüfung als XML.)

Eine andere Sache ist, dass viele Leute Angst vor Konstrukteuren haben; sie verstehen sie nicht, sie mögen sie nicht, sie wollen sie lieber nicht benutzen.

Mike Nakis
quelle
3
Stimmen vor allem mit der XML-Bemerkung überein. IMHO, Angst vor Konstruktoren zu haben, ist wahrscheinlich ein schlechter Grund, ein DI-Framework zu verwenden.
Robert Harvey
2
IMHO, Angst vor Konstrukteuren zu haben, ist ein guter Grund, sich von der Programmierung fernzuhalten. C -: =
Mike Nakis
5
Aber wie ist das ein Vorteil gegenüber einer Fabrik (statisch oder anders)? (Was den Vorteil hat, eine Option zu sein, die Sie je nach Bedarf verwenden können, während der Frühling alles oder nichts zu sein scheint)
Richard Tingle
@RichardTingle Spring kann einen Vorteil darstellen, vor allem aufgrund all der anderen Dinge, die es neben DI tut, da Sie DI offensichtlich auf viele andere Arten erreichen können, wobei statische Fabriken eine sind. (Eines der am wenigsten coolen, aber immer noch.) Aber die Frage ist, ob es notwendig ist, Feder zu verwenden, um DI zu erreichen, und das habe ich versucht zu beantworten: Im Grunde ist es nicht notwendig, nur eine Annehmlichkeit .
Mike Nakis
Dies ist ein Beispiel dafür, was DI nicht ist. ´TopLevel` sollte nicht erzeugen MiddleLevel, sondern beim Konstruieren TopLevelals Argument an den Konstruktor erhalten. Ebenso MiddleLevelsollte ein LowLevelin seinem Konstruktor erhalten.
Klarer
1

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

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

In meinem Fall habe ich das gefunden

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

  2. Durch die Verwendung eines DI-Frameworks von Drittanbietern müssen Sie das Rad nicht neu erfinden.

Paul J Abernathy
quelle
4
Könnten Sie näher erläutern, warum die Definition der zu verwendenden konkreten Klasse in einer XML-Datei besser ist als in einer Java-Datei? Das habe ich noch nie verstanden.
Richard Tingle
1
Es ist kein Wundermittel, aber ein Vorteil der Verwendung von Konfigurationsdateien besteht darin, dass sie zumindest theoretisch einfacher zu bearbeiten sind als Code. Außerdem können sie von einem Benutzer geändert werden, der Ihr Programm ausführt, aber keinen Zugriff auf Ihren Quellcode hat. In dem Beispiel, das ich für mein grobes Dependency Injection-Programm gegeben habe, habe ich manchmal die XML-Konfigurationsdatei geändert, damit ich ändern konnte, wie das Programm lief, obwohl ich derjenige war, der es geschrieben hat. Wenn Sie die externe Konfigurierbarkeit nicht benötigen, kann es einfacher sein, dies mit Code zu tun. Ich hatte einen anderen Job, bei dem wir alle DI im Code gemacht haben und das hat gut funktioniert.
Paul J Abernathy