Je m'excuse si cela semble être une autre répétition de la question, mais chaque fois que je trouve un article sur le sujet, il parle principalement de ce qu'est DI. Donc, je reçois DI, mais j'essaie de comprendre le besoin d'un conteneur IoC, dans lequel tout le monde semble se lancer. Le but d'un conteneur IoC est-il vraiment juste de "résoudre automatiquement" l'implémentation concrète des dépendances? Peut-être que mes classes ont tendance à ne pas avoir plusieurs dépendances et c'est peut-être pourquoi je ne vois pas le problème, mais je veux m'assurer que je comprends correctement l'utilité du conteneur.
Je divise généralement ma logique métier en une classe qui pourrait ressembler à ceci:
public class SomeBusinessOperation
{
private readonly IDataRepository _repository;
public SomeBusinessOperation(IDataRespository repository = null)
{
_repository = repository ?? new ConcreteRepository();
}
public SomeType Run(SomeRequestType request)
{
// do work...
var results = _repository.GetThings(request);
return results;
}
}
Il n'a donc qu'une seule dépendance, et dans certains cas, il peut en avoir une deuxième ou une troisième, mais pas souvent. Donc, tout ce qui appelle cela peut passer son propre référentiel ou lui permettre d'utiliser le référentiel par défaut.
En ce qui concerne ma compréhension actuelle d'un conteneur IoC, tout ce que fait le conteneur est de résoudre IDataRepository. Mais si c'est tout ce qu'il fait, alors je n'y vois pas une tonne de valeur car mes classes opérationnelles définissent déjà un repli lorsqu'aucune dépendance n'est passée. Donc, le seul autre avantage auquel je peux penser est que si j'ai plusieurs opérations comme ceci utilise le même dépôt de secours, je peux changer ce dépôt en un seul endroit qui est le registre / usine / conteneur. Et c'est très bien, mais c'est tout?
ConcreteRepository
et (2) vous pouvez fournir des dépendances supplémentaires à ConcreteRepository
(une connexion à la base de données serait courante, par exemple).