StructureMap DI auf Modell Assembly

Question

Ich bin neu Injection Abhängigkeit und hatte eine Frage / Notwendigkeit Führung.

Ich hatte eine Anwendung, die das Repository-Muster für den Datenzugriff verwendet. Ich benutzen StructureMap das richtige Repository zu bekommen und alles hat gut funktioniert.

Ich habe seit meinem Modell ausgebrochen (einschließlich der Repository-Logik) in seine eigene Montage und hat eine Service-Schicht. Im Interesse der DI nimmt die Service-Layer-Klasse eine IRepository in seinem Konstruktor. Dies scheint falsch zu mir jetzt alle Verbraucher meines Modells brauchen, um über das Repository (zumindest konfigurieren ihre DI zu wissen, was man verwenden) kennen. Ich fühle mich wie das in den Eingeweiden des Modells zu bekommen.

Was ist mit dem klingt falsch?

Answer 1

Eine Anwendung geschrieben Dependency Injection verwenden konfiguriert typischerweise eine einzige Container-Instanz, in der alle Schnittstelle / Implementierung Typzuordnungen in einer Initialisierungsphase der Anwendung registriert wurden. Dies würde die Registrierung der Repositories, Dienstleistungen umfasst, und alle Verbraucher des Service innerhalb der Anwendung.

, um die Verbraucher des Dienstes durch den Behälter von der Lösung, die Verbraucher müssen nur angeben, ihre Abhängigkeit von dem Dienst, keine Abhängigkeiten der Dienst benötigen. Daher werden die Verbraucher der Service nicht auf seine Abhängigkeiten gekoppelt werden (z Repository). Dies ist der Vorteil von Dependency Injection durch einen Behälter zu tun, im Gegensatz zu manueller Dependency Injection zu tun.

Wenn Sie Dienste entwerfen von anderen Anwendungen in Form einer wieder verwendbaren Bibliothek verbraucht werden dann Ihre Optionen werden je nach dem Grad an Flexibilität variieren Sie anbieten wollen.

Wenn Sie alle Clients Ihrer Bibliothek vermuten, wird Dependency Injection verwenden möchten, dann müssen Sie eine angemessene Menge an Unterlagen zur Verfügung zu stellen, welche Arten müssen in ihrem Container registriert sein.

Wenn Sie davon ausgehen, erhalten alle Kunden einen bestimmten Container (z StructureMap) verwenden möchten, dann können Sie die Registrierungsanforderungen erleichtern, indem Register schaffen, die für den Kunden alle spezifischen Bedürfnisse Registrierung kapseln.

Wenn Sie Ihre Bibliothek zu ermöglichen, von den Kunden ihre eigene Dependency Injection Container nicht verwendet werden, mit dann können Sie eine statische Fabrik zur Verfügung stellen, die den Dienst zurückgibt. Je nach dem Grad der Komplexität, ein solches Szenario erfordert nicht die Verwendung eines Behälters (zum Beispiel, wenn Ihr Dienst wird von nur wenigen Objekte in allen enthalten). Wenn Ihre Bibliothek einer beträchtlichen Menge von Komponenten bestehen, die zusammengesetzt werden müssen, dann könnten Sie Fabriken, die die Dienste durch eigene gemeinsame interne Infrastruktur Initialisierung Bedürfnisse lösen.

Answer 2

Ich verstehe Ihr Dilemma es Dan, auch ich verbrachte viel Zeit Ringe über das in meinem Kopf. Ich glaube, die Art, wie ich mit einem der besten Möglichkeiten war, vorwärts zu gehen entschieden alle Bedenken zu kapseln und immer noch leicht zu pflegende lose gekoppelten Objekte haben.

Ich schrieb diese Blog-Post speziell über NHiberante aber wenn man sich das Repository-Muster aussieht in implementieren können Sie bequem den NH-spezifischen Code ändern, um Ihre Backings zu verwenden.

anlegen gemeinsame generische und erweiterbare NHiberate Repository