Oba wzorce wydają się implementacją zasady odwrócenia kontroli. Oznacza to, że obiekt nie powinien wiedzieć, jak skonstruować swoje zależności.

Wydaje się, że Dependency Injection (DI) używa konstruktora lub selektora do „wstrzykiwania” zależności.

Przykład użycia wtrysku konstruktora:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

Wygląda na to, że lokalizator usług używa „kontenera”, który steruje jego zależnościami i daje foo to pasek.

Przykład korzystania z lokalizatora usług:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo()
  {
    this.bar = Container.Get<IBar>();
  }

  //...
}

Ponieważ nasze zależności są tylko obiektami, zależności te mają zależności, które mają jeszcze więcej zależności i tak dalej. W ten sposób narodził się kontener inwersji sterowania (lub kontener DI). Przykłady: Zamek Windsor, Ninject, Mapa struktury, Wiosna itp.)

Ale wygląda kontener IOC / DIdokładnie jak lokalizator usług. Czy nazywanie go pojemnikiem DI jest złą nazwą? Czy kontener IOC / DI jest kolejnymrodzaj lokalizatora usług? Czy niuans w tym, że korzystamy z DI Container głównie wtedy, gdy mamy wiele zależności?