Ambos patrones parecen una implementación del principio de inversión de control. Es decir, que un objeto no debe saber cómo construir sus dependencias.
La inyección de dependencias (DI) parece usar un constructor o setter para "inyectar" sus dependencias.
Ejemplo de uso de inyección de constructor:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
//...
}
Service Locator parece usar un "contenedor", que conecta sus dependencias y le da a su barra.
Ejemplo de uso de un localizador de servicios:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo()
{
this.bar = Container.Get<IBar>();
}
//...
}
Debido a que nuestras dependencias son solo objetos en sí mismas, estas dependencias tienen dependencias, que tienen incluso más dependencias, y así sucesivamente. Así nació la Inversión de Control Container (o DI Container). Ejemplos: Castillo Windsor, Ninject, Mapa de Estructura, Primavera, etc.)
Pero un contenedor IOC / DI se ve exactamente como un localizador de servicios. ¿Es un mal nombre llamarlo contenedor DI? ¿Es un contenedor IOC / DI simplemente otro tipo de localizador de servicios? ¿Es el matiz el hecho de que usamos contenedores DI principalmente cuando tenemos muchas dependencias?