Dependency Injection vs. Factory Pattern

Question

Die meisten der Beispiele, die für die Verwendung von Dependency Injection angeführt werden, können wir auch mit dem Factory Pattern lösen. Es sieht so aus, als ob der Unterschied zwischen Dependency Injection und Factory bei der Verwendung/Entwicklung verschwommen oder dünn ist.

Jemand hat mir einmal gesagt, dass es darauf ankommt, wie man es benutzt!

Ich habe einmal StructureMap einen DI-Container, um ein Problem zu lösen. Später habe ich ihn so umgestaltet, dass er mit einer einfachen Fabrik funktioniert und die Verweise auf StructureMap entfernt.

Kann mir jemand sagen, was der Unterschied zwischen ihnen ist und wo was zu verwenden ist, was die beste Praxis hier?

Answer 1

IOC ist ein Konzept, das auf zwei Arten umgesetzt wird. Erstellung von Abhängigkeiten und Injektion von Abhängigkeiten, Factory/Abstract factory sind das Beispiel für die Erstellung von Abhängigkeiten. Die Injektion von Abhängigkeiten besteht aus Konstruktor, Setter und Schnittstelle. Der Kern von IOC besteht darin, nicht von den konkreten Klassen abhängig zu sein, sondern eine abstrakte Methode zu definieren (z. B. eine Schnittstelle/abstrakte Klasse) und diese abstrakte Methode zu verwenden, um die Methode der konkreten Klasse aufzurufen. Wie beim Factory-Muster wird die Basisklasse oder Schnittstelle zurückgegeben. Ähnlich wird bei der Dependency Injection die Basisklasse/Schnittstelle verwendet, um Werte für Objekte festzulegen.

Answer 2

Meine Gedanken:

Dependency Injection: Übergabe von Kollaborateuren als Parameter an die Konstrukteure. Dependency Injection Framework: eine generische und konfigurierbare Fabrik zur Erstellung der Objekte, die als Parameter an die Konstruktoren übergeben werden.

Answer 3

Ich hatte die gleiche Frage, als ich über DI las und landete bei diesem Beitrag. Also schließlich ist das, was ich verstanden, aber bitte korrigieren Sie mich, wenn ich falsch bin.

"Vor langer Zeit gab es kleine Königreiche mit eigenen Regierungsorganen, die auf der Grundlage ihrer eigenen schriftlichen Regeln kontrollierten und Entscheidungen trafen. Später bildete sich eine große Regierung, die all diese kleinen Regierungsorgane abschaffte, die eine Reihe von Regeln (Verfassung) hat und durch Gerichte umgesetzt wird.

Die Regierungsorgane der kleinen Königreiche sind "Fabriken".

Die große Regierung ist der "Dependenz-Injektor".

Answer 4

Einfach ausgedrückt: Dependency Injection vs. Factory-Methode bedeutet Push- bzw. Pull-Mechanismus.

Zugmechanismus Klasse: Die Klasse ist indirekt von der Factory-Methode abhängig, die wiederum von den konkreten Klassen abhängig ist.

Druckmechanismus : Die Wurzelkomponente kann mit allen abhängigen Komponenten an einem einzigen Ort konfiguriert werden, was eine hohe Wartungsfreundlichkeit und eine lose Kopplung fördert.

Bei der Factory-Methode liegt die Verantwortung für die Erstellung eines neuen Objekts immer noch bei der Klasse (wenn auch indirekt), während bei der Dependency Injection diese Verantwortung ausgelagert wird (allerdings auf Kosten einer undichten Abstraktion).

Answer 5

Mit einer Fabrik können Sie verwandte Schnittstellen gruppieren. Wenn also die übergebenen Parameter in einer Fabrik gruppiert werden können, ist dies auch eine gute Lösung für constructor overinjection Sehen Sie sich diesen Code an *):

public AddressModelFactory(IAddressAttributeService addressAttributeService,
        IAddressAttributeParser addressAttributeParser,
        ILocalizationService localizationService,
        IStateProvinceService stateProvinceService,
        IAddressAttributeFormatter addressAttributeFormatter)
    {
        this._addressAttributeService = addressAttributeService;
        this._addressAttributeParser = addressAttributeParser;
        this._localizationService = localizationService;
        this._stateProvinceService = stateProvinceService;
        this._addressAttributeFormatter = addressAttributeFormatter;
    }

Sehen Sie sich den Konstruktor an, Sie müssen nur die IAddressModelFactory dort, also weniger Parameter *):

 public CustomerController(IAddressModelFactory addressModelFactory,
        ICustomerModelFactory customerModelFactory,
        IAuthenticationService authenticationService,
        DateTimeSettings dateTimeSettings,
        TaxSettings taxSettings,
        ILocalizationService localizationService,
        IWorkContext workContext,
        IStoreContext storeContext,
        ICustomerService customerService,
        ICustomerAttributeParser customerAttributeParser,
        ICustomerAttributeService customerAttributeService,
        IGenericAttributeService genericAttributeService,
        ICustomerRegistrationService customerRegistrationService,
        ITaxService taxService,
        CustomerSettings customerSettings,
        AddressSettings addressSettings,...

Sie sehen in CustomerController eine Menge von Parametern übergeben, Ja, Sie können dies sehen als constructor overinjection aber so funktioniert die DI. Und nein, es ist nichts falsch mit dem CustomerController .

*) Der Code stammt von nopCommerce.