Beide Muster scheinen eine Umsetzung des Prinzips der Umkehrung der Kontrolle zu sein. Das heißt, dass ein Objekt nicht wissen sollte, wie seine Abhängigkeiten zu konstruieren sind.
Dependency Injection (DI) scheint einen Konstruktor oder Setter zu verwenden, um seine Abhängigkeiten zu "injizieren".
Beispiel für die Verwendung von Constructor Injection:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
//...
}Service Locator scheint einen "Container" zu verwenden, der seine Abhängigkeiten verdrahtet und foo seine Bar gibt.
Beispiel für die Verwendung eines Service Locator:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo()
{
this.bar = Container.Get<IBar>();
}
//...
}Da unsere Abhängigkeiten nur Objekte selbst sind, haben diese Abhängigkeiten Abhängigkeiten, die noch mehr Abhängigkeiten haben, und so weiter und so fort. So wurde der Inversion of Control Container (oder DI Container) geboren. Beispiele: Castle Windsor, Ninject, Structure Map, Spring, usw.)
Aber ein IOC/DI Container sieht aus genau wie ein Service Locator. Ist die Bezeichnung "DI-Container" ein schlechter Name? Ist ein IOC/DI-Container nur ein weiterer Typ von Service Locator? Liegt die Nuance in der Tatsache, dass wir DI-Container meist dann verwenden, wenn wir viele Abhängigkeiten haben?
