什么时候适合直接依赖IoC容器本身？

我刚刚创建一个WorkQueueService，它可以处理不同类型的WorkItems。对于每种类型的WorkItem，我将实现IWorkItemProcessor。我正在使用IoC，因此所有IWorkItemProcessor实现都将在容器中注册。我的WorkQueueService将需要为每个WorkItem获取适当的处理器。什么时候适合直接依赖IoC容器本身？

问题是我应该让我的WorkQueueService直接依赖容器吗？或者我应该将这个责任抽象成一个WorkItemProcessorFactory，它只是IoC容器的一个小包装？

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

来源

2010-01-19 Samuel Jack

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

国际奥委会容器，因为很好的工厂提取;未来它可以被更好的容器取代。
与IOC容器交互的知识/复杂性被封装在明确的工厂中。团队中的所有成员无需了解特定IOC容器的功能。

来源

2010-01-19 10:57:40

+1抽象工厂是解决这类DI挑战的常见解决方案。你不应该直接依赖容器。 – 2010-01-19 11:18:19

IoC容器是一个工厂。我认为没有必要包装它，除非你认为你会交换不同的实现。

抽象是美妙的，但在某些时候所有的分层必须结束，你必须写一个具体的实现。我看不到包装IoC容器的价值。

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

来源

2010-01-19 10:56:52 duffymo

@duffymo：我想我可以给WorkQueueService WorkItemProcessors的集合，但是那就需要通过收集打猎找到每个工作项目相应的类型：我宁愿给容器reposnsibility不管怎样。 – 2010-01-19 11:00:54

什么时候适合直接依赖IoC容器本身？

回答

相关问题