如果您的工厂将IOC容器作为构造函数参数，然后使用该容器来解析接口。
通常声明only place the container should be referenced是您的应用程序入口点（Composition Root）。在工厂安装容器违背了这个
这是反模式吗？ 这不好吗？ 还有其他选择吗？
答案 0 :(得分：1)
如果您需要在应用程序内部构建对象并且这些对象需要依赖性解析，则可以执行的操作很少。你会发现许多关于使用它作为某些问题的可行解决方案的博客文章，但是你仍然可以用2种方式解决它（至少）withohut直接暴露组合根之外的容器（邪恶，可避免和糟糕的实践）。 / p>
1）您在CompositionRoot中将工厂创建为Lambda方法，大多数框架允许这样做（如果您需要复杂的初始化并且您的框架不允许初始化但允许注册“自定义注入器”，您可能需要在代码的极少数地方）。
2）在FactoryClass中包装容器的“build”（或等效名称）方法，然后将FactoryClass注入更具体的Factory，进行额外的初始化步骤（如果需要），否则你直接注入FactoryClass（大多数框架可能会为你注入这种工厂）。
在这两种情况下，没有明确引用CompositionRoot之外的Container并且阻止“服务定位器”模式（通过允许用户访问导致难以调试副作用的所有内容而导致意外的依赖性，特别是当您处理程序员不了解依赖注入和可维护性问题。
当然，IoC容器的主要目的之一是删除用户代码中对“new”的调用，允许分离创建和使用，因此大多数人只是在工厂内调用“new”并防止某些代码膨胀（它是关于“单一责任”原则，工厂的责任是“创造”，因此对于大多数人来说，更简单，最可维护的解决方案是直接使用“新”。