DI - Unity, Spring.net, LightCore etc. Integration in Architektur

Hallo liebe Community,

beschäftige mich seit kurzer Zeit mit Dependency Injection / Inversion of Control. Denke auch, dass ich das Prinzip verstanden habe! Was ich allerdings nicht ganz verstanden habe ist, wenn man jetzt Unity etc. einsetzt, wie integriert man es in die Architektur?

Wird DI in jedem Layer (Business/Service/Presentation/DA) verwendet? D.h. wird in jedem Layer ein Verweis auf das entsprechende Framework gesetzt?

Und ganz besonders, wie lege ich fest welche Objekte über den Container geladen werden und welche direkt instanziert werden? Hab das so verstanden, wenn ich mir sicher bin, dass ein entsprechendes Objekt nie wieder geändert werden muss, kann es direkt instanziert werden, ansonsten über DI! Lieg ich da richtig?

Dies steht alles im Zusammenhang damit, dass ich momentan ein größeres Projekt plane und die Architektur sowie Klassendiagramme usw. festlege! Jetzt möchte ich halt von Anfang an DI mit in die Planung einbeziehen! Dabei ist mir aufgefallen, dass ich gar nicht richtig weiß wie das integriert wird!
Hoffe ihr könnt mir dazu einen kleinen Anstoß geben!

Viele Grüße

Pico1184

Ich denke es ist sinnvoll einmal ein kleines Projekt damit zu bauen, kann ja ein kleiner Taschenrechner sein o.ä. nur um das Prinzip und die Funktionen des Frameworks zu verstehen. Man kann es sich stark erleichtern wenn man vorher viel liest und wie hier fragt, aber die Praxis ist der bester Lehrer und die sollte man haben bevor man ein Konzept erstellt. Dabei hilft es den ein oder anderen Fehler schon einmal slebst begangen zu haben.

Aber zu deiner Frage:
Generell muss man sich überlegen wie weit man IoC einsetzt. Dann muss auch in jeder assembly die IoC assembly (z.B. lightCore, kann ich emphelen) refferenziert sein.

Wird DI in jedem Layer (Business/Service/Presentation/DA) verwendet? D.h. wird in jedem Layer ein Verweis auf das entsprechende Framework gesetzt?

Also Ja, in jedem Layer der etwas registrieren will und den Zugang zum IoC Framework benötigt.

Dann die Frage:
Hast du Dynamische Teile die du gerne per XML Konfigurieren willst, oder reicht es alles per Code zu initialisieren.
Gerade bei der XML Methode wird es schwerer zu überblicken was nun im Container ist und was nicht und man sollte sich klare Grenzen schaffen was nun über den Container geladen wird und was direkt initialisiert wird. Wenn du Controller hast sollten z.B. alle Controller auch im Container sein und nicht einzelne gesondert behandelt werden.

Und ganz besonders, wie lege ich fest welche Objekte über den Container geladen werden und welche direkt instanziert werden? Hab das so verstanden, wenn ich mir sicher bin, dass ein entsprechendes Objekt nie wieder geändert werden muss, kann es direkt instanziert werden, ansonsten über DI! Lieg ich da richtig?

Entweder alles in die Container, oder bestimmte Gruppen von Klassen oder Namespaces ausschließen. Ich denke es wird unübersichtlich wenn man für jede einzelne Klasse die man braucht in die Doku gucken muss wo man die nun her bekommt.

Hi,

Idealerweise sollte der IoC Container nur an sehr wenigen Stellen explizit in Erscheinung treten, nämlich dann, wenn neue "Top-Level Objekte" erstellt werden. Alle direkten und indirekten Abhängigkeiten werden automatisch vom Container aufgelöst.

Nehmen wir als Beispiel eine ASP.NET MVC Anwendung. Ausgangspunkt des Requests ist der Controller. Die Erstellung des Controllers übernimmt eine IControllerFactory. Die Implementierung der Factory kann den IoC Container verwenden, um Controller aufzulösen. Alle direkten und indirekten Abhängigkeiten des Controllers kann und soll der Container rekursiv bitte selbständig auflösen. Je nach Architektur könnte der Controller z.B. diverse Referenzen auf Services benötigen, oder einen Service Bus, oder Objekte aus dem DAL usw. Ein Service wiederum könnte diverse andere Objekte benötigen, die der IoC automatisch auflöst. Dieses "Per-Request Setup" lässt sich ausgehend vom Controller vollständig automatisch vom IoC-Container auflösen, ohne dass irgendwo explizit der IoC-Container angesprochen wird.

Manchmal müssen neue "Top-Level Objekte" aber auch explizit erstellt werden, z.B. wenn eine Methode zur Laufzeit neue Domainobjekte erzeugen muss, die selbst wieder diverse Abhängigkeiten haben. An solchen Stellen kann man entweder den Container direkt bemühen, oder man führt eine kleine Abstraktionsebene ein, indem man eine Factory anbietet, die intern den IoC-Container verwendet. Letzteres macht besonders dann Sinn, wenn die zu erstellenden Objekte nach dem reinen Erzeugen noch mehr Konfigurationsarbeit benötigen. Außerdem reduziert man damit die zu wartende "Oberfläche" (Interface Segregation Principle). Die Controllerfactory von oben ist ein Beispiel hierfür. Übrigens kann man sowohl den IoC-Container als auch eine eventuelle Factory gleichfalls als Dependency an die gewünschten Stellen injizieren. Das beliebte IoC-Container-Singleton ist mMn für die allermeisten Situationen unnötig und unelegant.

Man muss den Umgang mit DI und IoC-Containern ein bisschen "trainieren", aber man bekommt relativ schnell ein gutes Gefühl dafür.

Grüße,
Andre

Salute zusammen

Also Ja, in jedem Layer der etwas registrieren will und den Zugang zum IoC Framework benötigt.

In den meisten Fällen, muss du das DI-Framework nicht referenzieren, siehe Posting von VizOne.

Idealerweise sollte der IoC Container nur an sehr wenigen Stellen explizit in Erscheinung treten, nämlich dann, wenn neue "Top-Level Objekte" erstellt werden. Alle direkten und indirekten Abhängigkeiten werden automatisch vom Container aufgelöst.

Da stimme ich zu.

Dazu noch:

• http://www.des-eisbaeren-blog.de/post/2009/12/07/Dependency-Injection-ist-keine-Silberkugel.aspx

Gruss Peter