Ich habe eine Klasse mit Abhängigkeiten, die ich mit Ninject verdrahtet habe.
%Vor%In der realen Implementierung verwende ich Property-Injection, aber nur um schnell zu veranschaulichen, werde ich auf das Feld spritzen. Wie ich es verstehe, anstatt Instanzen von MyObject neu zu erstellen, muss ich
verwenden, um die Abhängigkeiten richtig zu injizieren %Vor%Ich stolpere jedoch darüber, dass MyObject nur im Kontext einer Klassenbibliothek verwendet wird. Die Absicht ist, dass Endanwendungen ihre eigenen Module erstellen und sie in eine Kernel-Instanz zum Hydratisieren übergeben. In Anbetracht dessen, was ist normalerweise der pragmatischste Weg, um eine generische Instanz eines Ninject-Kernels auf meine Klassenbibliothek zu bringen, so dass Instanzen von MyObject (und anderen ähnlichen Fällen) hydratisiert werden können?
Meine erste Neigung ist eine Art Fabrik, die einen Singleton-Kernel internalisiert - den die Anwendungen selbst durch Laden eines Moduls hydratisieren / initialisieren müssen.
Also in RandomService.cs
%Vor%Bevor ich jedoch diesen Weg zu weit gehe, muss ich eine Plausibilitätsprüfung durchführen, um sicherzustellen, dass das Denken gesund ist oder dass es keine offensichtliche andere Sache gibt, die ich vermisse. Ich bin offensichtlich neu in IoC und fühle mich wie ich die Grundlagen, aber nicht unbedingt die besten realen Möglichkeiten, um es zu verwenden.
Ich bin mir nicht sicher, ob ich alle Details in Ihrer Frage verstehe, aber ich verlange, soweit ich verstehe, wie Sie die Abhängigkeit von Ninject externalisieren können.
Es ist möglich, DI-freundliche Bibliotheken zu schreiben, ohne jemals auf einen bestimmten DI-Container zu verweisen (Ninject oder irgendetwas anderes). Dies lässt den Verbraucher der Bibliothek offen, um den DI-Behälter seines oder ihres Geschmacks zu wählen (oder überhaupt keinen Behälter zu verwenden). Dieser Ansatz ist sehr bevorzugt, da er einen größeren Freiheitsgrad bietet.
Sie sollten jedoch Constructor Injection gegenüber Property Injection bevorzugen. Obwohl Property Injection täuschend einfach zu implementieren scheint, ist es ziemlich schwierig, richtig zu machen.
Einer der großen Vorteile von Constructor Injection ist, dass Sie dem Konstruktor keine Attribute hinzufügen müssen, da er strukturell bereits alle Informationen enthält, die ein DI-Container benötigt, um ihn korrekt zu verkabeln.
Marks Punkt ist definitiv meine Anfangsansicht (daher ein +1) darauf. Bitte vergessen Sie nicht, seinem Link zu folgen .
Ich für meinen Teil war schuldig in der Vergangenheit, Konstrukteur über Eigenschaften (oder Felder) zu früh aufzugeben (meine "Entschuldigung" war, dass eine Basisklasse 5 Eigenschaften benötigte, die ich nicht alle abgeleiteten Klassen damit belasten wollte). Die Lösung dafür war, die 5 Eigenschaften, die in einer Klasse oder Hierarchie von Klassen involviert sind, zu umhüllen, die die zugrundeliegenden Konzepte darstellen, die die Eigenschaften repräsentieren. Ein bisschen wie das Refactoring des Einführen-Parameter-Objekts.
Eine gute Diskussion der Überlegungen, die ich für nützlich hielt, ist Ссылка (cant Suchen Sie den SO-Post, der es erwähnt und einige Themen um ihn herum, vielleicht wird jemand einen Link einwerfen: D)
Ein weiterer Blog, der einige dieser Punkte zusammenfasst, ist Ihr IoC-Container wird angezeigt
Und Ссылка
Hier ist ein schönes allgemeines Rezept zum Finden aller ninject Module in der aktuellen Assembly:
%Vor%Tags und Links design-patterns ioc-container ninject