CIO - L'injection de dépendances multiples

Question

Considérons le ci-dessous:

public class DependencyA {} 
public class DependencyB {} 
public class DependencyC {} 
public class DependencyD {} 

public class Service1 
{ 
    public Service1(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service2 
{ 
    public Service2(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service3 
{ 
    public Service3(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 

Je constate que beaucoup de mes services dépendent de plusieurs éléments communs, et je pense à mettre en œuvre une prise de solution comme ci-dessous (tous câblé via Windsor) pour éviter la répétition du code dans les constructeurs de Service.

public class DependencyContainer 
{ 
    public DependencyA A { get; set; } 
    public DependencyB B { get; set; } 
    public DependencyC C { get; set; } 
    public DependencyD D { get; set; } 
} 

public class Service1 
{ 
    public Service1 (DependencyContainer container) { ... } 
} 

Vous pouvez également créer une classe ServiceBase. La vraie question est-ce que cela met en évidence un problème de conception plus large dans les services? Peut-être que je prends trop de DI, mais ce sont toutes des dépendances authentiques.

Si oui, comment puis-je coder autour de cela? Sinon, la solution proposée est-elle un moyen valable d'atteindre cet objectif?

Answer 1

Avoir trop de dépendances sur vos services pourraient montrer que votre service est en train de faire trop de choses. En d'autres termes, il viole probablement le principe de la responsabilité unique.

Answer 2

Il est difficile de parler du problème sans contexte plus large, mais vous pouvez avoir affaire à des dépendances trop fines. Est-ce que les quatre dépendances appartiennent ensemble? Ont-ils un sens en tant qu'un tout cohérent?

Si oui, votre approche est très valable.

Si ce n'est pas le cas, vous risquez de vous heurter à un mur dans votre architecture. Vous avez peut-être partitionné votre domaine de telle sorte que les responsabilités qui devraient être placées dans une ou plusieurs entités (implicitement existantes) sont attachées à d'autres entités. Dans ce cas, vous devriez regarder dans votre domaine et essayer d'identifier ces entités implicites récurrentes, les rendre explicites et déplacer le comportement en eux. C'est toutefois un problème beaucoup plus difficile, et très spécifique à votre domaine et votre application.

Et cela n'a rien à voir avec IoC