如何理解规则:IoC容器应该只在Bootstrapper中明确使用?

时间:2011-09-12 02:19:16

标签: dependency-injection unity-container ioc-container

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

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

1)瞬态寿命 - 由于我们在启动时建立基础设施,所有对象应该处于“应用程序生命周期”并且通常应该是单身;如果我们需要创建一些“每次调用”对象,那么使用IoC我们只解析他们的抽象工厂,这应该创建“每个调用”的基础结构对象(避免“嵌套”容器和“瞬态”容器的实例); 2)子容器,父/子容器; 3)“等级生活时间”。

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

1 个答案:

答案 0 :(得分:4)

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

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

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

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