如何理解规则:IoC 容器应该仅在 Bootstrapper 中显式使用?

发布于 12-04 05:24 字数 478 浏览 1 评论 0原文

我的理解正确吗 1)理想情况下,resolve方法应该只调用一次并一次性构建整个应用程序图。 2) 库的类应该为 IoC 工具做好准备(发布所有依赖项),但不应“秘密”使用任何 IoC 容器;因此,我们应该避免在除“bootsrapper”之外的任何其他层上创建容器的情况。 3) 将 IContainer 发送到子类以进行额外的“解决”也是失败的决定。

这些原则对我来说非常合乎逻辑,我分享它们。但我在回答这个问题时仍然有疑问:“为什么仍然使用这样的概念......”

1)瞬态生命周期 - 因为我们在启动时构建基础设施,所以所有对象都应该存在“应用程序生命周期”并且通常应该是单身人士;如果我们需要创建一些“每次调用”对象,那么使用 IoC 我们只解析它们的抽象工厂,这应该创建“每次调用”基础设施对象(避免“嵌套”容器和“瞬态”容器实例); 2)子容器、父/子容器; 3)“层次结构生命周期”。

现在我为自己解释这些概念的存在是为了“没有理想世界”的解决方案,但我可能错过了什么吗?

Am I right in understanding that
1) Ideally, resolve method should be called only once and build whole application graph at one bout.
2) Library's classes should be ready for IoC tool (publish all dependencies) but should not use "secretly" any IoC containers ; so the situations where we create container on any other layers except "bootsrapper" should be avoided.
3) Send of IContainer to subclusses for additional "resolvings" is also abortive decision.

Those principles are very logical for me, I share them. But I still have doubts in answering on this question: "why there are still used such concepts like.."

1) transient life-time - since we build infrastructure on start-up all objects should live "application life-time" and generally should be singletons; if we need to create some "per call" objects then with IoC we resolve only theirs abstract factories, which should create "per call" infrastructure objects (avoiding "nested" containers, and "transient" container's instances);
2) subcontainers, parent/child containers;
3) "hierarchy life time".

Now I explain for my self that those concepts exists as solutions for "no ideal world", but may be I miss something?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

小苏打饼2024-12-11 05:24:02

即使您只解析单个对象图(例如在桌面应用程序中就是这种情况),Transient 仍然与 Singleton 不同,因为您可能有一个由多个使用者使用的抽象(例如 ILog 接口)。如果生命周期为Transient,则每个消费者将获得自己的实例,但如果生命周期为Singleton,则所有消费者将共享同一个实例。

共享实例通常是更可取的,因为它使用较少的资源,但可能存在线程安全等问题,因此您始终需要考虑权衡。

当您考虑基于请求的应用程序(例如网站或服务)时,整个讨论就会被放大。对于此类应用程序,单例可以在许多不同的请求之间共享,但必须是线程安全的,而瞬态对象更安全,但效率较低。

有些容器具有每个网络请求的生活方式,可以为这些情况提供中间解决方案,但那些通常不具有分层或基于上下文的生活方式的容器可用于解决相同的场景,因为您可以为每个 HTTP 请求创建一个容器范围。

Even if you only resolve a single object graph (which would be the case e.g. in a desktop application), Transient is still different from Singleton because you might have an abstraction which is used by multiple consumers (e.g. an ILog interface). If the lifetime is Transient, each consumer will get its own instance, but if the lifetime is Singleton, all consumers will share the same instance.

Sharing an instance is often preferable because it uses less resources, but may have issues with thread-safety etc. so you always need to consider the tradeoffs.

This whole discussion is just enlarged when you consider request-based applications, such as web sites or services. For such applications, Singletons can be shared across many different requests, but must be thread-safe, whereas Transient objects are safer, but less efficient.

Some containers have a per web request lifestyle to provide a middle-of-the-road solution for those cases, but those that don't often have a Hierarchical or context-based lifestyle which can be used to address the same scenario, since you can create a container scope per HTTP request.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文