大型项目中的最佳 IoC 实践
您发现哪些技术可用于管理大型项目与控制反转容器的依赖关系？
您是否将所有内容集中在一处，还是将其分开？
您曾经使用过多个容器吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
您发现哪些技术可用于管理大型项目与控制反转容器的依赖关系？
您是否将所有内容集中在一处，还是将其分开？
您曾经使用过多个容器吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（1）
从架构的角度来看，保持对您的 组合根是。它应该尽可能靠近应用程序的入口点，并且您应该在一个地方构建整个依赖关系图。
否则可能会造成责任混乱，并且您还可能面临引入所有依赖关系的风险 。各种微妙的错误，因为在一个地方解析的 IFoo 实例可能与在另一地方解析的 IFoo 实例相同，也可能不同。
如果应用程序太大，以至于一次性解析整个依赖关系图的成本过高，您可以使用 延迟加载生命周期在战略位置（大约
从概念上讲，我总是只有一个容器。 （我偶尔会使用多个父/子容器来打破一些循环依赖关系，但这是一个实现细节。）
From an architectural viewpoint it's important to maintain a razor-sharp focus on where your Composition Root is. It should be as close to the application's entry point as at all possible, and you should compose the entire dependency graph in a single place.
Doing otherwise can create confusion about responsibilities, and you also risk to introduce all sorts of subtle bugs because the IFoo instance resolved in one place may or may not be the same as an IFoo instance resolved in another place.
If the application is so large that resolving an entire dependency graph in one go simply is prohibitively expensive, you can address this by using lazy loading lifetimes in strategic places (around Aggregate Services).
Conceptually, I always only have a single container. (I occasionally have multiple parent/child containers in play to break some circular dependencies, but that's an implementation detail.)