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?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您已经发现的，依赖注入 (DI) 本身只是模式和技术的集合。
在应用程序的根部，我们连接了所有必要的对象图。这个地方叫做Composition Root，我们可以使用DI容器来为我们进行此接线，或者我们可以手动进行（纯 DI）。
关键是，您的应用程序中只有一个地方强烈引用了一项特定的技术（您的 DI 容器）。应用程序的其余部分完全不知道对象图是如何连接的 - 重要的是所有必需的依赖项都已正确注入（并且您可以将构造函数注入与Null Guards 保证确实如此）。
对于 DI 来说，抽象工厂模式是一个非常有用的模式。本质上，在以下情况下使用抽象工厂：
示例和更多信息可在此处找到：
As you have already figured out, Dependency Injection (DI) itself is only a collection of patterns and techniques.
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).
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).
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:
在应用程序的最顶部，您将需要一个加载 IOC 上下文的 Bootstrap 类。然后，该上下文将提供实际实例化的对象，因此充当工厂。
但这应该只发生在很少的对象上，并且 Bootstrap/Factory 类的用户应该尽可能少地了解底层架构。例如，如果您完全通过 IOC 配置了 HTTP 服务器对象，并且想要启动它，则 Bootstrap 类只需要提供 getHttpServer() 方法。那么你的程序 main 方法只需要调用 Bootstrap.getHttpServer().start() 即可运行。
其他对象的连接已经由应用程序上下文完成，例如，您通过 IOC 配置对象 A，它是对象 B 的一部分，因此您可以通过引用对象 A 来配置对象 B。它们通常都不需要了解容器也不是工厂。
Well at the top most part of your application you will need a Bootstrap class that loads the IOC context. This context then will provide the actually instantiated objects and therefore acts as a factory.
But this should only happen with very few objects and the user of your Bootstrap/Factory class should know as little about the underlying architecture as possible. For example if you configured a HTTP server object completely via IOC and you want to start it your Bootstrap class only needs to provide a getHttpServer() method. Then your programs main method only needs to call Bootstrap.getHttpServer().start() to get it running.
The wiring of your other objects has already been done by the application context e.g. you configure Object A via IOC which is part of Object B so you configure Object B with the reference to Object A. None of them usually need to know neither about the container nor the factory.