inversion-of-control - IoC 之上的抽象工厂模式？

Question

我决定在更大的项目中使用 IoC 原则。然而，我想弄清楚一些困扰我很长时间的事情。我得出的结论是，IoC 容器是一种架构模式，而不是设计模式。换句话说，任何类都不应该知道它的存在，并且容器本身应该在应用程序层使用来缝合所有组件。从本质上讲，它成为一个选项，位于精心设计的面向对象模型之上。话虽如此，如何在不到处散布 IoC 容器的情况下访问已解析的类型(无论它们是否是抽象的)？我在这里看到的唯一选择是利用抽象工厂，它使用 IoC 容器来解析具体类型。这应该很容易替换为一组标准工厂。这是一个好方法吗？这里有人用过它吗？它对你来说效果如何？还有其他可用的吗？

谢谢!

Answer 1

正如您已经发现的，依赖注入(inject) (DI) 本身只是模式和技术的集合。

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

重点是，您的应用程序中只有一个地方强烈引用了一项特定的技术(您的 DI 容器)。应用程序的其余部分完全不知道对象图是如何连接的 - 重要的是所有必需的依赖项都已正确注入(inject)(并且您可以将构造函数注入(inject)与空守卫以保证事实如此)。

对于 DI 来说，抽象工厂模式是一个非常有用的模式。本质上，在以下情况下使用抽象工厂:

• 您需要提供一个或多个仅在运行时已知的参数，然后才能解决依赖项。
• 从概念上讲，依赖项的生命周期比使用者的生命周期短。

示例和更多信息可在此处找到:

• 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