Les deux modèles semblent comme la mise en œuvre du principe de l'inversion de contrôle. C'est, qu'un objet ne doit pas savoir construire ses dépendances.
L'Injection de dépendance (DI) semble utiliser un constructeur ou un setter pour "injecter" ses dépendances.
Exemple d'utilisation du Constructeur d'Injection:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
//...
}
Service de Localisation semble utiliser un "conteneur", qui relie ses dépendances et donne foo c'est un bar.
Exemple d'utilisation d'un Localisateur de Service:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo()
{
this.bar = Container.Get<IBar>();
}
//...
}
Parce que nos dépendances sont juste des objets eux-mêmes, ces dépendances les dépendances, qui ont même plus les dépendances, et ainsi de suite et ainsi de suite. Ainsi, l'Inversion de Contrôle du Conteneur (ou DI Containor) était né. Exemples: Château de Windsor, Ninject, la Structure de la Carte, Printemps, etc.)
Mais un CIO/DI Conteneur ressemble exactement comme un Localisateur de Service. Est de l'appeler une DI Containor un mauvais nom? CIO/DI Conteneur juste un autre type de Service Locator? Est la nuance dans le fait que nous utilisons DI Conteneurs surtout lorsque nous avons beaucoup de Dépendances?
