Comments on: HowTo: Dependency Injection & Service Locator

By: HowTo: WCF ClientChannel über Windsor Castle erstellen–WCF & IoC… | Code-Inside Blog

Wed, 27 Jul 2011 22:30:20 +0000

[...] Es wird aber etwas knifflig, wenn man es nun sich den Proxy für den WCF Aufruf über einen DI (Was ist eigentlich “Dependency Injection/DI”?) Container aufbauen lassen möchte. In diesem Beispiel wird der DI Container Windsor Castle benutzt [...]

By: HowTo: Alle Implementationen vom Interface X über Castle Windsor per DI auflösen | Code-Inside Blog

Sun, 27 Jun 2010 22:24:45 +0000

[...] kleinen Einstieg hab ich hier bereits gegeben. In meinem Beispiel nutze ich Castle Windsor, genauso gut hätte ich wahrscheinlich [...]

By: Robert Mühsig

Robert Mühsig — Thu, 10 Jun 2010 14:18:27 +0000

Hallo Ron,
das hast du genau richtig erkannt. Die IInstanceFactory geht eher in die Richtung “Worst-Practices” weil es quasi ein ServiceLocator ist.
Dort ist das Problem halt, dass man a) nie genau weiß, was die Klasse überhaupt für Abhängigkeiten hat und b) dass man keine wirkliche Kontrolle hat, weil die Klasse ganz wild Services aufrufen kann.

Mein unteres Beispiel mit WindsorCastle und dem Aufruf von “container.Resolve();” würde automatisch die Abhängigkeiten aufschlüsseln und hätte die Intelligenz die du ansprichst.

Dabei sucht WindsorCastle automatisch nach dem Konstruktor, welcher die meisten Abhängigkeiten entgegennimmt und schlüsselt diese dann immer weiter auf.

By: Ron

Ron — Tue, 08 Jun 2010 15:06:16 +0000

Hallo Robert,

es gibt bekanntlich keine dumme Fragen, also riskierÂ´ ichÂ´s mal…

Die Klasse UserService: IUserService stellt ja einen Konstruktor für Constructor Injection bereit:
UserService(IInstanceFactory factory) { … }

Mit IOC-Containern wie Castle Windsor oder LightCore kann man nun über die Konfigurationsdateien “anmelden”, dass der Konstruktor der Klasse UserService (oder bzw. die Klasse als solche) eine Abhängigkeit von IInstanceFactory besitzt. Soweit richtig?

Ich hätte mir aber folgendes von einem IOC-Container gewünscht: Damit ich mich beim Schreiben der Konfiguration für den IOC-Container eben NICHT MEHR darum kümmern muss, welche Abhängigkeiten die Klasse Kunde per Constructor Injection nennt, soll der IOC-Container selbst erkennen (bspw. über Reflection), dass UserService eine IInstanceFactory benötigt, selbständig prüfen, ob es schon eine Instanz von ILogger gibt, und wenn nicht, selbige aufgrund der Konfiguration eigenständig instanzieren und dann erst den Konstruktor von UserService aufrufen.

Anders ausgedrückt: Soweit ich das Konzept von LightCore oder CastleWindsor richtig verstanden habe, muss ich mich ja immer noch selbst darum kümmern, dass die Abhängigkeit der Klasse X vom Typ Y (weil als Konstruktorargument erwartet) irgendwo (z.B. in der Konfiguration) “angemeldet” wird.
Erhofft hätte ich mir eine entsprechende Intelligenz des IOC-Containers; habe ich hier etwas übersehen oder ist das so?

Herzlichen Dank für Deine Meinung,
Gruß
Ron

By: Rainer Hilmer

Rainer Hilmer — Tue, 16 Mar 2010 10:10:50 +0000

Hallo Robert,
schöne Einführung in das Thema. Was hier vielleicht nicht so ganz deutlich geworden ist: Ein weiterer Vorteil von DI und IOC ist, neben der Testbarkeit, die einfache Möglichkeit, Komponenten auszutauschen (Komponentendesign). So ist es z.B. ein Leichtes Serialisierungskomponenten auszutauschen (XML gegen binary or whatever). Wichtig dabei ist nur daß diese Komponenten eine gemeinsame Kommunikationsschnittstelle (Interface) implementieren. Mit diesem Verfahren lassen auch Presentation Layer austauschen. Mit der richtigen Architektur kann man die gleiche Applikation mit einem Web-UI verbinden oder z.B. mit Windows Forms.
Gruß
Rainer

By: Alexander Groß

Alexander Groß — Tue, 16 Mar 2010 08:37:07 +0000

Hallo Robert,

eine sehr schöne Zusammenfassung!

Alex