您发现哪些技术可用于使用Inversion of Control容器管理大型项目的依赖关系？
你是在一个地方引导所有东西，还是将它拆开？
您使用过多个容器吗？
答案 0 :(得分：8)
从架构的角度来看，重要的是要保持对Composition Root所在位置的敏锐关注。它应该尽可能接近应用程序的入口点，并且你应该在一个地方组成整个依赖图。
否则可能会造成关于责任的混淆，并且您还有可能引入各种微妙的错误，因为在一个地方解决的IFoo实例可能与在另一个地方解决的IFoo实例相同或不同。
如果应用程序太大而无法一次性解析整个依赖图，那么您可以在战略位置（lazy loading lifetimes附近）使用Aggregate Services来解决这个问题。
从概念上讲，我总是只有一个容器。 （我偶尔会有多个父/子容器来打破一些循环依赖，但这是一个实现细节。）