在 .NET 的同一解决方案中使用两个 IoC 容器的缺点？

我正在开发一个项目，该项目使用来自其他开发人员的一组库，该库使用结构图 http://structuremap.github.io作为 IoC 容器。 [我有代码库]

我们合并这些库的应用程序使用统一容器 https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff647202(v=pandp.10).

在同一个解决方案中使用两个容器框架有缺点吗？我想将所有内容移至同一个 IoC 容器，但如何证明额外工作的合理性？

在同一个容器中拥有多个容器库是有区别的solution与相同应用，因为一个解决方案可以由多个可运行的应用程序组成。

所有组件都应连接到应用程序的启动路径中，即成分根 https://freecontent.manning.com/dependency-injection-in-net-2nd-edition-understanding-the-composition-root/:

组合根是应用程序中模块组合在一起的（最好）唯一位置。

与构造函数注入一起使用，组合根模式使您的应用程序保持完整松耦合，并使您的应用程序代码与 DI 容器分离。

根据组合根模式，应用程序的任何其他部分都不应该依赖于 DI 容器。事实上，您使用的库确实存在问题，因为这会迫使您进入某个 DI 容器。更好的解决方案是让库DI 友好 https://blog.ploeh.dk/2014/05/19/di-friendly-library/.

在同一个容器中拥有多个容器库有一些缺点solution:

• 您必须学习两个不同的 DI 容器库，每个库都有其局限性和怪癖
• 每个库都有其自身的风险，需要在以下情况下进行更换：发展 https://jeremydmiller.com/2018/01/29/sunsetting-structuremap/ stops https://blogs.msdn.microsoft.com/dotnet/2015/08/21/the-future-of-unity/.

最重要的是，在同一个容器中使用多个容器库有一些缺点应用:

• 当单个对象图由来自不同容器的应用程序组件构建时，可能会出现复杂性。可视化对象图并验证它们的正确性可能很困难。
• 如果某个组件从两个容器中解析，则可能会导致撕裂的生活方式 https://simpleinjector.org/diatl

这并不是说您永远不应该在同一个解决方案或应用程序中拥有多个容器。例如，您可以使用两个容器作为临时解决方案，因为您要从一个库迁移到下一个库，但大爆炸式迁移的工作量太大。理想情况下，在这种情况下，您可以一次迁移一个应用程序，但即使如此，也可能会难以一次性完成。

拥有两个容器就可以的另一个常见场景是，您正在运行的应用程序框架在内部使用 DI 容器来构建其服务。这些框架的常见示例是 ASP.NET Core 和 NServiceBus。在这种情况下，为了清楚地区分，我通常会谈论框架的配置系统而不是它的内部容器，因为这就是它的本质。它是一个容器，是一个实施细节.

在这种情况下，您可以按原样保留内置“配置系统”来解决框架组件，并使用您选择的 DI 容器来构建对象图应用程序组件.