Architecture 什么时候可以直接依赖IoC容器本身？

我正要创建一个WorkQueueService，它可以处理不同类型的工作项。对于每种类型的工作项，我都有一个IWorkItemProcessor的实现。我使用的是IoC，因此所有IWorkItemProcessor实现都将在容器中注册。我的WorkQueueService需要为每个工作项获取适当的处理器

问题是我应该让我的WorkQueueService直接依赖于容器吗？或者我应该将这个职责抽象到WorkTemprocessorFactory中，而WorkTemprocessorFactory只是IoC容器的一个薄包装

---

其他人在这种情况下做了什么？为什么？

IoC容器是一个工厂。我认为包装它没有任何意义，除非您认为您要交换不同的实现

抽象是美妙的，但在某个时刻，所有的分层都必须结束，您必须编写一个具体的实现。我认为包装IoC容器没有任何价值

---

为什么依赖必须是明确的？如果WorkQueueService有一个IWorkItemProcessor集合，其数量在IoC中是可配置的，为什么不像其他依赖项一样注入该集合呢？我不明白为什么WorkQueueService需要对IoC容器的引用。

建议您通过创建工厂来抽象容器。只有工厂才应该知道容器。它有两个好处：

IOC容器，因为被工厂很好地抽象；将来可以用更好的容器来代替它

与IOC容器交互的知识/复杂性封装在定义良好的工厂中。团队中的所有成员无需了解特定IOC容器的功能

---

@duffymo：我想我可以给WorkQueueService一个WorkTempProcessor集合，但是它需要在集合中查找每个工作项的适当类型：我宁愿给容器一个这样或那样的可报告性。+1抽象工厂是解决这种DI挑战的一个非常常见的解决方案。您不应该直接依赖于容器。