在IoC顶部的抽象工厂模式？

Question

我决定在更大的项目中使用IoC原则。但是，我想得到的东西很长一段时间一直困扰着我。我得出的结论是IoC容器是一种架构模式，而不是一种设计模式。换句话说，没有类应该知道它的存在，并且应该在应用层使用容器本身来缝合所有组件。从本质上讲，它是一个精心设计的面向对象模型的选择。 话虽如此，如何在不占用IoC容器的情况下访问已解析的类型（无论它们是否抽象）？我在这里看到的唯一选择是利用使用IoC容器来解析具体类型的抽象工厂。这应该很容易换掉一组标准工厂。这是一个好方法吗？有没有人在这里使用它，它对你有用吗？还有其他什么吗？

谢谢！

Answer 1

正如您已经想到的那样，依赖注入（DI）本身只是模式和技术的集合。

在应用程序的根目录，我们连接了所有必要的对象图。这个地方叫Composition Root，我们可以使用DI容器为我们做这个布线，或者我们可以手动完成（Pure DI）。

关键在于，您的应用程序中只有一个地方可以强烈引用特定的技术（您的DI容器）。该应用程序的其余部分幸福地没有意识到对象图如何连接 - 所有重要的是所有必需的依赖项都被正确注入（并且您可以使用构造函数注入 Null Guards 以保证确实如此。

对于DI，抽象工厂模式是非常有用的模式。实质上，在以下情况下使用Abstract Factory：

• 在解决依赖关系之前，您需要提供仅在运行时已知的一个或多个参数。
• 依赖的生命周期在概念上比消费者的生命周期短。

此处提供了示例和更多信息：

• Is there a pattern for initializing objects created via a DI container
• Can't combine Factory / DI
• Which DI container will satisfy this
• Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
• Design - Where should objects be registered when using Windsor

Answer 2

在应用程序的最顶层部分，您需要一个加载IOC上下文的Bootstrap类。然后，此上下文将提供实际实例化的对象，因此充当工厂。

但这应该只发生在很少的对象上，而Bootstrap / Factory类的用户应该尽可能少地了解底层架构。例如，如果您通过IOC完全配置了HTTP服务器对象并且想要启动它，则您的Bootstrap类只需要提供getHttpServer（）方法。然后你的程序main方法只需要调用Bootstrap.getHttpServer（）。start（）来使它运行。

其他对象的连线已由应用程序上下文完成，例如：您通过IOC配置对象A，它是对象B的一部分，因此您可以使用对象A的引用来配置对象B.它们通常不需要知道容器和工厂。