Wie IoC Container Dependency Injection implementiert im Vergleich zu dem, wie ich es implementieren würde

Question

Um Dependency Injection zu machen, könnte ich ein generisches Wörterbuch mit verschiedenen Typen von DB-Verbindungen erstellen und dann einen Typ dynamisch durch Reflexion instanziieren, bevor ich ihn an den Konstruktor des Objekts übergebe, das ihn benötigt.

Welchen Unterschied und Nutzen bringt es, wenn ich einen IOC Container verwende, da er meine Sachen nicht unabhängiger macht als die erste Lösung. Wie würde sich der IOC Container intern verhalten? Ist er anders als die erste Lösung ?

Wie würden Sie DI ohne Container implementieren? Wann würden Sie zu einem IoC-Container wechseln?

Ich meine, gibt es eine andere Möglichkeit, DI zu implementieren, als die, an die ich gedacht habe, so dass ich den besten Weg nutzen könnte?

Answer 1

Dependency Injection hat nichts mit Wörterbüchern zu tun. Wie Nicholas Blumhardt in einem ausgezeichneten Blog-Beitrag erklärt, benötigen Sie eine vollständige anderes mentales Modell für DI .

DI ist eine lose Kopplung durch die Anwendung des Konstruktor Injektion y Zusammensetzung Wurzel Entwurfsmuster. Wenn ein DI-Container das Bild betritt, geschieht dies über die Register Resolve Release Muster.

Wenn eine Klasse also eine Datenbankverbindung benötigt, fordert sie diese über den Konstruktor an.

Answer 2

Ich nehme an, ein Container übernimmt einen Großteil des Standardcodes für Sie. Er tut zum Beispiel genau das, was Sie gesagt haben: Er instanziiert eine Klasse auf der Grundlage des reflektierten Verhaltens. Viele Container ermöglichen es Ihnen auch, Ihr System explizit auf der Grundlage von Konfigurationsdateien zu konfigurieren.

IOC oder DI sind nur Konzepte. IOC/DI-Konzepte geben Ihnen die "Unabhängigkeit", die Sie bevorzugen. Die tatsächliche Umsetzung kann variieren. Sie können es ohne die Verwendung eines Containers eines Drittanbieters machen - oder einen eigenen Container schreiben. Oder Sie können die von einem gut getesteten Container eines Drittanbieters bereitgestellten Funktionen nutzen.

Wenn Sie nur verschiedene Arten von DB-Verbindungen einspeisen wollen, haben Sie einen sehr geringen Bedarf an IOC/DI. Im Allgemeinen ist IOC/DI (Achtung, nicht der Container, der ist nur ein Umsetzung von IOC/DI) bietet Ihnen vollständig konfigurierbare Software, hilft bei Unit-Tests (durch Einfügen von Stubs), Selbstkonfiguration usw.

In der Regel ist IOC/DI erforderlich, wenn:

1. Ihre Software ist so umfangreich und komplex, dass keine einzelne Person alles im Kopf hat, oder
2. so viele verschiedene Konfigurationen hat, dass Sie keine benutzerdefinierten Builds wünschen, oder
3. so stark von den einzelnen Teilen abhängig ist, dass es schwierig ist, jedes Teil einzeln zu prüfen

Answer 3

Es gibt keine Vorschrift, die besagt, dass Sie einen IoC-Container verwenden müssen, es ist nur so, dass IoC-Container vorgefertigt sind und Sie den Code nicht selbst schreiben müssen. Das bedeutet, dass Sie sich auf die Entwicklung Ihrer Anwendung konzentrieren können, und nicht auf Ihr eigenes DI-System.

Es ist wie bei der Erstellung Ihrer Benutzeroberfläche oder der Verwendung eines Steuerelements eines Drittanbieters. Beides funktioniert, es hängt nur davon ab, wo Sie Ihre Zeit verbringen wollen. Ich weiß, dass ich nicht wirklich viel über den Aufbau meiner eigenen DI-System kümmern, so würde ich lieber eine vorgefertigte ein verwenden.

Man könnte genauso gut fragen, warum man überhaupt ein Framework verwendet, wenn man direkt in die Betriebssystem-APIs schreiben kann. Es geht darum, die Zuverlässigkeit zu verbessern (durch die Wiederverwendung von Code, den jemand anderes bereits geschrieben und viel Zeit damit verbracht hat, sicherzustellen, dass er fehlerfrei ist) und Ihre Produktivität zu steigern (indem Sie nicht alles selbst schreiben müssen).

EDIT:

Es gibt viele Möglichkeiten, DI umzusetzen. Sie können sich alle Container ansehen, die es gibt, und wie sie funktionieren. Sie sind alle Open Source, und der Quellcode ist verfügbar.