dependency-injection - 如何理解规则: IoC container should be explicitly used only in Bootstrapper?

Question

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

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

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

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

Answer 1

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

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

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

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