如何理解规则：IoC 容器应该只在 Bootstrapper 中显式使用？

Question

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

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

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

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

Answer 1

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

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

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

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