IoC之上的抽象工厂模式？ [英] Abstract factory pattern on top of IoC?

问题描述

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

I have decided to use IoC principles on a bigger project. However, i would like to get something straight that's been bothering me for a long time. The conclusion that i have come up with is that an IoC container is an architectural pattern, not a design pattern. In other words, no class should be aware of its presence and the container itself should be used at the application layer to stitch up all components. Essentially, it becomes an option, on top of a well designed object-oriented model. Having said that, how is it possible to access resolved types without sprinkling IoC containers all over the place (regardless of whether they are abstracted or not)? The only option i see here is to utilize abstract factories which use an IoC container to resolve concrete types. This should be easy enough to swap out for a set of standard factories. Is this a good approach? Has anyone on here used it and how well did it work for you? Is there anything else available?

谢谢！

推荐答案

已经知道，依赖注入（DI）本身只是模式和技术的集合。

As you have already figured out, Dependency Injection (DI) itself is only a collection of patterns and techniques.

在应用程序的根本，我们连接了所有必要的对象图。这个地方称为合成根，我们可以使用DI容器来请为我们进行此接线，也可以手动进行（纯DI

At the root of the application we wire up all necessary object graphs. This place is called the Composition Root, and we can use a DI Container to do this wiring for us, or we can do it manually (Pure DI).

要点是，您的应用程序中只有一个地方会强烈引用特定技术（您的DI容器）。该应用程序的其余部分非常高兴地不知道对象图是如何连接的-重要的是正确注入了所有必需的依赖项（并且您可以将 Constructor Injection 与空警卫队以确保确实如此）。

The point is that there's only one place in your application where there's a strong reference to a particular piece of technology (your DI Container). The rest of the app is blissfully unaware of how the object graph was wired up - all that matters is that all required dependencies were correctly injected (and you can use Constructor Injection with Null Guards to guarantee that this is so).

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

The Abstract Factory pattern is a very useful pattern when it comes to DI. In essence, use Abstract Factory when:

• 需要先提供一个或多个仅在运行时已知的参数，然后才能解析依赖项


• 从概念上讲，依赖项的生存期短于消费者的生存期。

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

Examples and more information is available here:

• 是否存在用于初始化通过DI容器创建的对象的模式


• 无法结合使用Factory / DI


• 哪个DI容器将满足此要求


• 我应该在哪里进行Ninject 2+的注入（以及如何布置模块？）


• 设计-使用Windsor时应在哪里注册对象

• 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

这篇关于IoC之上的抽象工厂模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！