Hat ein IoC-Container die Verwendung von Fabriken ersetzen

Question

Ich bin gerade mit IoC Container so Entschuldigungen Sie beginnen, wenn dies eine dumme Frage ist.

Ich habe Code wie folgt in einer App

internal static class StaticDataHandlerFactory
    {
        public static IStaticDataHandler CreateHandler(StaticDataUpdate staticDataUpdate)
        {
            if (staticDataUpdate.Item is StaticDataUpdateOffice)
            {
                return new OfficeUpdateHandler();
            }

            if (staticDataUpdate.Item is StaticDataUpdateEmployee)
            {
                return new EmployeeUpdateHandler();   
            }

            if (staticDataUpdate.Item == null)
            {
                throw new NotImplementedException(
                    string.Format("No static data provided"));
            }
            else
            {
                throw new NotImplementedException(
                    string.Format("Unimplemented static data type of {0}", staticDataUpdate.Item.GetType().FullName));
            }
        }
    }

Es ist im Grunde eine einfache Fabrik, die für den Umgang mit den Eingangsdaten der richtige Strategie zurück.

Würde ein IoC-Container erlauben Sie mir, Code wie diesen zu beseitigen? Das heißt: wäre es mir erlauben, dynamisch eine konkrete Umsetzung zu wählen, basierend auf der Art des Eingabeparameters an der Last,

Oder bin ich weg natürlich hier?

Answer 1

Eigentlich, obwohl es möglich ist, einen Teil des Codes mit einer Inversion des Steuersystems zu ersetzen, ist es mir nicht klar, es ist eine gute Idee. Dependency Injection neigt zur Konfiguration von Systemen am besten sein, nicht dynamische Erstellung von Objekten. Um es eine andere Art und Weise, der Behälter selbst ist eine große globale Variable und soll daher in viel von Ihrem Code erscheint.

Als beiseite, erscheint der Code die Gesetz von Demeter . Es scheint, dass die Parameter des Typs sein sollte „StaticDataUpdateItem“ statt „StaticDataUpdate“. Damit beobachtet, es ist ein ziemlich starkes Argument diesen Code als Methodenaufruf zum Umschreiben auf dem StaticDataUpdateItem.

Ich habe IoC ziemlich stark, aber dynamische Objekterstellung besser noch mit Verwendung einer Abstrakte Fabrik behandelt. Kurz gesagt, wenn Sie eine Methode um das Element der Zugabe selbst die Idee nicht gefällt, um den Griff zu erzeugen, ist der Code wahrscheinlich am besten links, wie es ist.

Answer 2

Sie sind nicht weit weg vom Kurs überhaupt; die Art, wie ich es verstehe, sind Sie ziemlich nahe.

Die Art und Weise würde ich am häufigsten diese Art der Sache strukturieren ist Ihre Factory-Klasse in Ihre IoC-Container zu machen, indem man einfach den UpdateHandlers ermöglicht, die Dependency Injection angegeben wird zurückgegeben zu verwenden. Anstatt also die Logik in Ihrem Code zu haben, der angibt, dass StaticDataUpdateOffice bedeutet OfficeUpdateHandler zurückzukehren, können Sie Ihren Code werden zu einfach zu sagen, dass StaticDataUpdateOffice gibt, was ein (neu spezifiziert) m_officeUpdateHandler Variable enthält; so lange, wie Ihr Rahmen stellt sicher, dass Sie den Wert m_officeUpdateHandler festlegen, bevor Sie Ihre Fabrik aufrufen, du bist gut zu gehen. Und Sie können den Wert des m_officeUpdateHandler zu etwas ändern Sie zur Laufzeit wollen, wie Ihre Anforderungen ändern.

Diese Dependency Injection ermöglicht es Ihnen, die Kontrolle über die Inversion of Control Prozess zu haben; Sie können eine einfache Fabrik haben, die Ihren Handler zurück, und Sie können abstrakt die Logik, die kontrolliert, was Handler an einen anderen Ort zurückgegeben wird, falls erforderlich.

. Hinweis: meine Erfahrung mit dieser Art der Sache ziemlich stark getrieben durch meine (sehr positiv) Erfahrung mit Spring, und so meine Interpretation Ihrer Frage, dass kann (und die Antwort) Farbe

Answer 3

Die kurze Antwort ist ja, es erlaubt es. Dieses Blogeintrag zeigt eine glatte Art und Weise Implementierung zur Laufzeit mit Windsor zu wählen. Der Autor, Ayende erarbeitet hier und hier .

Ich habe das noch nicht ausprobiert, aber ich erwarte, dass bald.

Answer 4

Ich bin damit einverstanden hier mit den anderen Antworten, dass ja, können Sie es auf diese Weise tun. Aber, warum Sie nicht eine allgemeine verwenden?

public static IStaticDataHandler CreateHandler<T>( params object[] args )
{...

Dabei gilt args als Ctor Argumente übergeben (auf zum Beispiel Activator) werden kann.

Answer 5

Ich habe noch keine Worte hier zu lesen, die viel Sinn machen.

IoC ist für Config?

Dynamische Objekterstellung ist besser, was? Generika? Das ist alles off topic.

1) IoC ist nichts anderes als eine nette Zeitersparnis im Vergleich zur Umsetzung der ‚Zusammensetzung über Spezialisierung / Vererbung‘ Evangelium.

So Regel # 1 für einen IoC verwenden ist, dass Sie wirklich müde sein sollten, mit langen Bauer beschäftigen zu haben, die dem ‚bind nicht der Durchführung von Aufträgen‘ folgen.

Anders ausgedrückt, ist dies die stratey Muster als Alternative über das Vorlagenmuster, aus den gleichen Gründen (kapseln ...) ... aber ist es mehr Arbeit all zusätzliche Schnittstelle / abstrakte Typen zu erstellen, und es ist mehr arbeiten, um es jedes Mal mit dem ganzen IServiceProvicerThis und IResolverThat zu tun ... Wenn Sie mit tediously nicht müde sind, um Code Verträge zu erfüllen, wie:

IInterestingService interessant = ... Sie eine Instanz erhalten jedoch ..

fügt über drei weitere Zeilen wie diese ..

dann

IAmazementService service = new AmazementService (interessant, thesecondstrategy, Die dritte, etc ...)

Das wird alt. So ist IoC nie eine Frage, weil jemand intelligent genug, um Code solide Konstruktion mit wäre es besser wissen. Diejenigen fragen haben alle die falschen Antworten.

Also, wenn in der Tat Sie die oben genannten treffen dann absolut. IoC Container sind an den Haken, so viel 'creational Arbeit zu tun, wie Sie aus der Vermietung sie beschäftigen profitieren können. Und die häufigste creational abstraaction über explizite neu ist Herr Factory.

Damon