Quand est-il approprié de prendre une dépendance directe sur le conteneur IoC lui-même?

Question

Je suis sur le point de créer un WorkQueueService capable de gérer différents types d'éléments de travail. Pour chaque type de WorkItem, j'aurai une implémentation de IWorkItemProcessor. J'utilise IoC, donc toutes les implémentations IWorkItemProcessor seront enregistrées dans le conteneur. Mon WorkQueueService devra obtenir le processeur approprié pour chaque WorkItem.

La question est de savoir si mon WorkQueueService dépend directement du conteneur? Ou devrais-je résumer cette responsabilité dans un WorkItemProcessorFactory qui serait juste un wrapper mince autour du conteneur IoC?

Qu'ont fait les autres dans cette situation et pourquoi?

Answer 1

Il est recommandé de faire abstraction des conteneurs en créant des usines. Seules les usines devraient être au courant des conteneurs. Il y a deux avantages à cela:

1. Conteneur IOC depuis bien résumé par les usines; il pourrait être remplacé par un meilleur conteneur à l'avenir. La connaissance/complexité de l'interaction avec le conteneur IOC est encapsulée dans une usine bien définie. Tous les membres de l'équipe n'ont pas besoin d'être au courant du fonctionnement d'un conteneur IOC particulier.

Answer 2

Le conteneur IoC est une usine. Je ne vois pas l'intérêt de l'envelopper, à moins que vous pensiez que vous allez échanger différentes implémentations.

Les abstractions sont merveilleuses, mais à un certain point, toute la superposition doit se terminer et vous devez écrire une implémentation concrète. Je ne vois aucune valeur dans l'emballage du conteneur IoC.

Pourquoi la dépendance doit-elle être explicite? Si le WorkQueueService possède une collection de IWorkItemProcessor, dont le nombre est configurable dans votre IoC, pourquoi ne pas injecter la collection comme n'importe quelle autre dépendance? Je ne vois pas pourquoi WorkQueueService a besoin d'une référence au conteneur IoC.