webentwicklung-frage-antwort-db.com.de

Was ist der wahre Unterschied zwischen "Bastard Injection" und "Poor Man's Injection"?

Aus dem Buch "Dependency Injection in .Net" weiß ich, dass der Objektgraph am Composition Root der Anwendung erstellt werden sollte, was für mich sehr sinnvoll ist, wenn Sie einen IoC-Container verwenden.

In allen Anwendungen, die ich gesehen habe, als ein Versuch unternommen wurde, DI zu verwenden, gibt es immer zwei Konstruktoren: den mit den Abhängigkeiten als Parameter und den "Standard" ohne Parameter, der den anderen als "newing" bezeichnet. alle Abhängigkeiten, aber in diesem Buch heißt das "Bastard Injection Anti-Pattern" und das war es, was ich als "Poor Man's Injection" kannte.

Wenn ich nun all dies bedenke, würde ich sagen, dass "Poor Man's Injection" einfach keinen IoC-Container verwendet und stattdessen alle Objektgraphen von Hand auf die besagte Composition Root codiert. 

Meine Fragen sind also:

  1. Verstehe ich diese Konzepte richtig oder bin ich völlig falsch?
  2. Wenn Sie immer noch alle Abhängigkeiten im IoC-Container registrieren müssen, anstatt sie manuell in genau demselben Kompositionsstamm zu codieren, was ist der eigentliche Vorteil der Verwendung eines IoC-Containers?
  3. Wenn ich falsch verstanden habe, was "Poor Man's Injection" wirklich ist, könnte jemand bitte das klarstellen?

Vielen Dank

oopdependency-injectionarchitecture
55
Sergio Romero

Wenn es um DI geht, gibt es eine Menge widersprüchlicher Terminologie. Der Begriff Poor Man's DI ist keine Ausnahme. Für manche Menschen bedeutet es eine Sache und für andere bedeutet es etwas anderes.

Eines der Dinge, die ich mit dem Buch machen wollte, war die Bereitstellung einer konsistenten Mustersprache für DI. Bei all diesen Begriffen mit widersprüchlicher Verwendung hatte ich zwei Möglichkeiten: Entscheide dich für einen völlig neuen Begriff oder wähle den gebräuchlichsten Gebrauch (nach meinem subjektiven Urteil).

Im Allgemeinen habe ich es vorgezogen, die vorhandene Terminologie erneut zu verwenden, anstatt eine völlig neue (und damit fremde) Mustersprache zu entwickeln. Das bedeutet, dass Sie in bestimmten Fällen (z. B. Poor Man's DI) eine andere Vorstellung davon haben können, wie der Name lautet, als in der Definition im Buch angegeben. Das passiert oft bei Musterbüchern.

Zumindest finde ich es beruhigend, dass das Buch seine Aufgabe zu erfüllen scheint, sowohl das Poor Man's DI als auch die von Bastard Injection genau zu erklären, da die im O.P.

Bezüglich des tatsächlichen Nutzens eines DI-Containers verweise ich auf diese Antwort: Argumente gegen Inversion von Kontrollcontainern

PS 2018-04-13: Ich möchte darauf hinweisen, dass ich vor Jahren erkannt habe, dass der Ausdruck Poor Man's DI eine schlechte (sic!) Arbeit von das Wesen des Prinzips kommunizieren, so habe ich jetzt stattdessen Pure DI genannt).

50
Mark Seemann

Einige Anmerkungen zu Teil 2 der Frage.

Wenn Sie immer noch alle Abhängigkeiten im IoC-Container registrieren müssen, anstatt sie manuell in genau demselben Kompositionsstamm zu codieren, was ist der eigentliche Vorteil der Verwendung eines IoC-Containers?

  • Wenn Sie über einen Baum von Abhängigkeiten verfügen (Klassen, die von Abhängigkeiten abhängen, die von anderen Abhängigkeiten abhängen usw.): Sie können nicht alle "Nachrichten" in einem Kompositionsstamm ausführen, da Sie die Instanzen für jede "Bastard-Injektion" neu erstellen Konstruktor jeder Klasse, so gibt es viele "Kompositionswurzeln", die entlang der Codebasis verteilt sind

  • Wenn Sie einen Abhängigkeitsbaum haben oder nicht, wird die Verwendung eines IoC-Containers das Eingeben von Code ersparen. Stellen Sie sich vor, Sie haben 20 verschiedene Klassen, die von derselben IDependency abhängen. Wenn Sie einen Container verwenden, können Sie eine Konfiguration angeben, um anzugeben, welche Instanz für IDependency verwendet werden soll. Sie erstellen dies an einer einzigen Stelle, und der Container achtet darauf, die Instanz in allen abhängigen Klassen bereitzustellen

  • Der Container kann auch die Objektlebensdauer steuern, was einen weiteren Vorteil bietet.

Abgesehen von den anderen offensichtlichen Vorteilen, die DI bietet (Testbarkeit, Wartbarkeit, Code-Entkopplung, Erweiterbarkeit ...)

4
JotaBe

Beim Überarbeiten älterer Anwendungen und der Entkopplung von Abhängigkeiten haben wir festgestellt, dass die Dinge in einem zweistufigen Prozess einfacher sind. Der Prozess umfasst sowohl "Arme" als auch formale IoC-Containersysteme.

Erstens: Richten Sie Schnittstellen ein und richten Sie die Implementierung mit "poor mans ioc" ein. 

  • Dies entkoppelt Abhängigkeiten ohne den zusätzlichen Aufwand (und die Lernkurve ) Eines formalen IoC-Setups.
  • Dies reduziert auch die Interferenzen mit dem vorhandenen Legacy-Code. Es gibt nichts Besseres, als noch ein weiteres Problem zu debuggen.
  • Mitglieder des Entwicklungsteams sind niemals auf dem gleichen Niveau an Fachwissen oder Verständnis. Das spart viel Implementierungszeit. 
  • Dies ermöglicht auch ein Fundament für Testfälle. 
  • Dies setzt auch später Standards für ein formales IoC-Containersystem.
  • Dies kann im Laufe der Zeit von vielen Personen schrittweise implementiert werden.

Zweitens: Jedes IoC-System hat Vor- und Nachteile. 

  • Jetzt, da ein Anwendungsstandard etabliert ist, kann eine fundierte Entscheidung Bei der Auswahl eines IoC-Containersystems getroffen werden. 
  • Die Implementierung des IoC-Systems wird zur Aufgabe des Austauschs des "Poor Mans" -Codes mit dem neuen IoC-System .
  • Dies kann schrittweise über die Zeit hinweg und parallel mit dem "armen Mann" implementiert werden. Es ist besser, dies mit einer Person zu leiten.
0
A A