Stellen Abhängigkeits-Injection-Frameworks ein Abhängigkeitsrisiko dar?

Ich habe ein vorhandenes System überarbeitet, um die Abhängigkeitsinjektion zu verwenden, und diese Arbeit verlief reibungslos.

Nach einer Weile bemerkte ich, dass eine große Anzahl von internen Bibliotheken von dem von mir verwendeten DI-Framework abhängig wurde. Infolgedessen hängt das gesamte Projekt jetzt von diesem Drittanbieter-Framework ab.

Ich sah eine Ironie darin, alle Abhängigkeiten zu entkoppeln, indem ich sie von einer gemeinsamen Bibliothek abhängig machte.

Meine erste Reaktion bestand darin, eine Wrapperbibliothek um das Abhängigkeitsframework zu erstellen. Daher könnte ich dieses Framework bei Bedarf ersetzen. Nachdem ich die damit verbundene Arbeit eingeschätzt hatte, stellte ich fest, dass die resultierende API dem vorhandenen Framework ähneln und es daher schwieriger machen würde, es zu ersetzen. Also habe ich die Idee aufgegeben.

Ich mache mir Sorgen, dass das DI-Framework, das ich verwende, veraltet ist oder ersetzt werden muss.

Gibt es bei der Arbeit mit DI ein Entwicklungsmuster, das die Kopplung zwischen einem Projekt und dem DI-Framework verringert?

frameworks dependency-injection

— Reactgular
quelle

Das Muster "Verwenden Sie kein DI-Framework". Obwohl ich mich fragen muss, ob Sie ein Problem lösen, das Sie nicht wirklich haben - wie wahrscheinlich ist es, dass Sie das DI-Framework ändern?

— Oded

@Oded Ein gutes DI-Framework sollte in der Lage sein, transparent mit Code zu arbeiten, aber es gibt Fälle, in denen dies nicht möglich ist. Sie müssen dann die DI-APIs in Ihren Klassen verwenden. In diesen Fällen ist es schwierig, das DI-Framework freizugeben oder zu ändern, ohne dass diese Klassen geändert werden müssen. Da ich zum ersten Mal mit diesem DI-Framework arbeite. Ich bin mir nicht sicher, ob ich es ersetzen muss.

— Reactgular

Ihr System ist auch von Strom abhängig. Ich schlage vor, Sie entkoppeln das zuerst.

— Idan Arye

@MathewFoscarini Ist das nicht ein Anti-Muster? Sie können es tun, aber Sie sollten es nicht tun, da es die Abhängigkeit verschleiert.

— Maaartinus

@MathewFoscarini DIFramework.Get<IService>()ist eigentlich keine Abhängigkeitsinjektion. Es handelt sich um ein ähnliches Muster namens Service Locator. Viele Leute mögen Service Locator nicht, weil es Sie mit dem Framework verbindet und zu leicht missbraucht wird (wie Singleton). Martin Fowler hat einen tollen Artikel über diese Muster: martinfowler.com/articles/injection.html

— Benjamin Hodgson

Antworten:

Sie haben völlig Recht - wenn Sie ein DI-Framework verwenden, hängt Ihr Code höchstwahrscheinlich von diesem Ding ab. Eigentlich ist das zu überraschend, da dies normalerweise für jede andere Framework- oder Foundation-Bibliothek zutrifft, insbesondere wenn diese Bibliothek Ihr Projekt mit einigen generischen Funktionen unterstützt, die überall in Ihrem Code verwendet werden. Wenn Sie sich beispielsweise für die Verwendung eines bestimmten UI-Frameworks oder Web-Frameworks entscheiden, kann diese Entscheidung nachträglich nur schwer geändert werden, sobald Sie eine bestimmte Codemenge basierend auf dieser Bibliothek erstellt haben. Wenn Sie sich für eine bestimmte (möglicherweise nicht standardmäßige) StringKlasse entscheiden, können Sie diese Entscheidung später nicht einfach ändern. Eine solche Entscheidung ist eine architektonische Entscheidung. Sie entspricht der Auswahl einer bestimmten Programmiersprache und versucht, diese Entscheidung zu ändern, nachdem Sie mehr als 100 KB Code geschrieben haben.

Es ist möglicherweise kein Problem, wenn Ihr gesamter Code von einem bestimmten Framework abhängt, solange er Ihren Erwartungen entspricht und ordnungsgemäß gewartet wird. Aber es kann zu einem Problem werden, wenn dies nicht der Fall ist. Es gibt einige Strategien, um mit dieser Situation umzugehen:

Wählen Sie ein Framework eines Anbieters, von dem Sie überzeugt sind, dass er Ihnen in einigen Jahren Updates und neue Releases bereitstellen kann
Wählen Sie ein Open-Source-Framework mit nur wenigen Codezeilen (und einer geeigneten Lizenz), damit Sie alle Wartungsarbeiten selbst durchführen können, wenn der Anbieter vom Markt verschwindet
Schreiben Sie Ihr eigenes Framework
Lebe mit der Situation, solange der Anbieter verfügbar ist. Wenn er wirklich verschwindet, wähle ein anderes Framework und versuche, einen Adapter zu erstellen, der das alte Framework mit dem neuen emuliert

Die Idee, eine Wrapper-Bibliothek im Voraus zu erstellen, ist überhaupt nicht neu, aber ich habe selten gesehen, dass dies funktioniert, da Sie Annahmen für eine zukünftige Situation treffen müssten, für die Sie nicht wissen, ob oder wann es Sie treffen wird und was Das "neue" Framework wird so aussehen. Andererseits haben wir vor einigen Jahren ein vollständiges UI-Framework in einem C ++ - Projekt mit ~ 120 KB Codezeilen erfolgreich ausgetauscht, indem wir die oben erwähnte Adapterstrategie angewendet haben.

— Doc Brown
quelle

Für die normale Konstruktorinjektion ist kein Framework erforderlich. Das einzige, was Sie verlieren, ist die Möglichkeit, Ihre Abhängigkeiten in einer Konfigurationsdatei zu zentralisieren.

DI-Container sind ein "Unternehmenssoftware" -Muster, das verwendet wird, wenn das Objektdiagramm sehr groß und komplex ist. Ich vermute, dass 95% der Bewerbungen dies nicht erfordern.

— Robert Harvey
quelle

Ich bin damit einverstanden, dass kleine Projekte dies nicht erfordern , aber 95% der Projekte können davon profitieren .

— Maaartinus

@maaartinus: Unnötige zusätzliche Komplexität für minimalen Nutzen.

— Robert Harvey

Was zum? Dies sind meine Statistiken pro Klasse: 0,5 Anmerkungen, 0,1 Konfigurationszeile. Also, welche Komplexität meinst du ???

— Maaartinus

@RobertHarvey: Obwohl ich Ihren obigen Aussagen zu 100% zustimme, gibt das OP an, dass er bereits ein DI-Framework eingeführt hat. Ihm "besser nicht" zu sagen, ist keine wirkliche Antwort auf seine Frage.

— Doc Brown

@maaartinus desto mehr werden die Rahmen automatisiert und desto mehr Material kann es die komplexeren injizieren. Es gibt XML-Konfigurationsdateien, Konstruktorinjektion, Eigenschaftsinjektion, automatische Objektverspottung, verzögerte Injektion usw. Diese DI-Frameworks können sehr komplex werden.

— Reactgular

Ich glaube nicht, dass DI-Frameworks bald wirklich überholt sein können. Was sollte passieren, um es überholt zu machen?

Eine Erfindung eines neuen und intelligenteren Musters vielleicht? Wie auch immer es aussehen sollte, es würde viel größere Änderungen im Code erfordern.
Ein Sprachwechsel vielleicht? Noch schlimmer.

Ich würde sagen, dass der aktuelle DI ausgereift genug ist und mir nicht bewusst ist, dass dort viel passiert. Sie haben Ihre Sprache nicht angegeben. Wenn Sie also von Guice sprechen , ist dies ziemlich unauffällig und funktioniert mit Standard-Java-Annotationen (verwendet auch ihre eigene Sprache für Dinge, die nicht standardisiert sind, die Sie aber selten benötigen). Es ist Open Source, weit verbreitet und Apache-lizenziert. Woran könnte das liegen?

Ich bin mir ziemlich sicher, dass das Ändern des DI-Frameworks um Größenordnungen einfacher wäre als das Ändern einer anderen Bibliothek (z. B. bedeutet eine Änderung der Benutzeroberfläche viel mehr Arbeit).

— maaartinus
quelle