Dependency Injection in einer n-Ebenen-Anwendung?

Question

Ich habe ein 3-Tier .NET Service App, die den Standardansatz folgt:

Frontend -> Object Model / Business Logic -> Data Access

Ich versuche, über Dependency Injection auf dem Weg zu lernen, und bisher haben sie große (mit Autofac) gefunden. Jede der drei Ebenen muss eine Auswahl von Objekten erstellen, manchmal mit zusätzlicher Konfiguration / etc. Es scheint, wie die DI-Container sollte die ideale Sache, dies zu lösen, aber ich habe einige Probleme zu sehen, wo es in Bezug auf den Rest des Systems leben soll.

Zur Zeit habe ich eine Klasse im Frontend, die den DI-Container konfiguriert. Es ist im Grunde ein großer Haufen von Code sagt container.Register<SomeType>() und so weiter.

Das Problem ist, es den Behälter für alle drei Ebenen wird die Konfiguration, und daher muss ziemlich invasive Kenntnis der Datenzugriffsschicht haben. Mit Code in meinem Frontend mit einem solchen Wissen aufbricht Alarmglocken in meinem Kopf als der Punkt der Trennung der App in Stufen ist diese genaue Situation zu vermeiden.
Dies wird auch durch die Tatsache verschlimmert, dass meine Datenzugriffsschicht ist nicht nur SQL Server einen stummen Eimer von Bits sein, ist aber aus vielen komplexen COM-Interop und P / Invoke Anrufe, so hat durchaus einen Einfluss auf die DI gemacht Konfiguration.

Ich habe einige Gedanken zu brechen es aufgegeben - vielleicht pro Tier einen Behälter mit oder in jeder Stufe eine „Setup“ Klasse, die mit dem globalen DI-Container spricht registrieren es eigene Bits ist, aber ich bin nicht sicher, ob das wird mehr Probleme verursachen als sie löst ...

Ich würde es wirklich schätzen, wenn jemand ihre Erfahrungen im Umgang mit DI mit vielschichtiger Anwendungen gemeinsam nutzen kann.

Danke, Orion.

Answer 1

Das hängt davon ab, ob Sie drei Ebenen (physikalische Trennung) haben oder wenn alle logischen Schichten miteinander eingesetzt. Wenn das Frontend ist getrennt von Ihrem BL und kommuniziert über einen Webservice oder WCF dann das Frontend und das Backend braucht, um ihre eigenen Container, weil sie in separaten Prozessen oder separaten Maschinen laufen. Die Behälter würden nur ihre eigenen Komponenten und die Schnittstellen der ‚nächsten‘ Schicht registrieren.

Auf der anderen Seite, wenn alle Schichten werden in diesem Prozess ausgeführt wird, dann sollten Sie nur einen Container haben. Der Behälter würde im Ausgangspunkt der Anwendung wie global.asax für eine Webanwendung initialisiert und gehostet wird.

Das Problem mit dem Host-Container zu viel von all den verschiedenen Teilen des Systems zu wissen, könnte durch nicht registriert die Klassen eins nach dem anderen gelöst werden, sondern alle Typen in einer Assembly registrieren. Auf diese Weise brauchen Sie nicht zu stark Verweise auf alle Baugruppen in Ihrer Lösung nur um den Behälter zu konfigurieren. Beispiel dafür, wie das mit Schloss Winsdor getan werden:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));