Hallo Oliver,
Wenn Du eine Zeile wie:
IPerson person = new Person();
in deinem Code kompilierst, ist die Referenz person für immer und ewig an die konkrete Implementierung von Person gebunden. Du könntest - wie bereits gezeigt - diese Instazierung hinter einer Factory-Methode verbergen:
IPerson person = PersonFactory.Create("Max Müller"); // gibt Person, Employee, Manager zurück
und das wäre schon ein Tick besser, denn innerhalb von PersonFactory könntest Du jetzt z.B. nicht einfach eine Instanz von Person zurückgeben, sondern vielleicht eine davon abgeleitete Klasse wie Employee, oder Manager. PersonFactory.Create() könnte z.B.
Max Müller in einer Datenbank nachschlagen, sehen dass er ein Angestellter ist und daraufhin eine Employee-Instanz zurückgeben (immer vorausgesetzt, dass Employee die Schnittstelle IPerson implementiert). Der Aufrufer-Code wäre dadurch nicht mehr direkt abhängig
von einer bestimmten Implementation.
Natürlich muss die zurückgegeben Instanz irgendwie erstellt werden, entweder über
new oder über Reflection (Activator.CreateInstance()). Wenn Du
new verwenden willst, musst Du die Assembly referenzieren in der der zu instanzierende Typ steht. Das musst Du nicht tun, wenn Du die Instanz über Reflection erstellst.
Und eben deshalb verwenden DI-Container eher die Reflection-Methode. Der Sinn ist ja die Entkopplung des Consumer-Codes vom Implementierungs-Code. Dein Consumer-Code betrachtet den Container als Black-Box. Deshalb sagt der Consumer-Code zum Container: "Gib
mir bitte irgendeine Instanz die IPerson implementiert". Und der Container antwortet: "Da bei mir als Implementationstyp für IPerson z.Z. die Klasse Employee registriert ist, werde ich gemäß der eingerichteten Auflösungsregeln für dich eine Instanz
von Employee erstellen und sie dir zurückgeben."
Die Klasse Employee könnte nun in irgendeiner Assembly stehen von der die Aufrufer-Assembly keine Kenntnis hat. Was ich nicht weiß, mach mich nicht heiß. Ändert sich die Implementation von
Employee, musst Du die aufrufende Assembly nicht neu kompilieren, Du kannst die neue Assembly einfach so verteilen und der DI-Container sorgt dafür, dass alle zufrieden sind. Will der Kunde B kein Employee verwenden sondern eher Instanzen von
ContingentWorker, sei's drum, für der Aufrufercode ändert sich nichts. Neue Assembly eingespielt und weiter geht's.
Nun stell dir einmal vor, dass der Konstruktor von Person viele Argumente benötigen würde, z.B.
IPerson person = new Person(new SocialSecurityNumber(new UsCitizenshipInfo()), new PersonName());
wäre es nicht bequemer, statt diesen Konstruktor 100x überall im Code zu verwenden, einfach eine vorgefertigte Instanz vom Container zu verlangen?
IPerson person = Container.Resolve<IPerson>();
Der Container kennt die zu instanzierende Klasse, er kennt alle ihre Abhängigkeiten und kann dir die händische Arbeit ersparen.
Ich versuche hier zu vereinfachen. Wenn Du aber das ganze Bild sehen willst, lies Marc Seemans Buch Dependency Injection in .NET, Manning Publications, 2011.
Gruß
Marcel
