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

Question

我正在开发一个项目，该项目使用来自其他开发人员的一组库，这些库使用structuremap作为IoC容器。 [我和我有代码库]

我们合并这些库的应用程序使用unity container。

在同一解决方案中拥有两个容器框架是否存在缺点？我想将所有内容移到同一个IoC容器中，但我如何证明额外的工作量呢？

Answer 1

在同一个解决方案中使用多个容器库与使用相同的应用程序之间存在差异，因为解决方案可以包含多个可运行的应用程序。

应该在应用程序的启动路径中连接所有组件，例如Composition Root：

  

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

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

根据Composition Root模式，应用程序的其他任何部分都不应该依赖于DI Container。您使用的库所做的事实是有问题的，因为这会迫使您进入某个DI容器。更好的解决方案是创建库DI-friendly。

在同一个解决方案中拥有多个容器库有一些缺点：

• 您必须学习两个不同的DI容器库，每个库都有其局限性和怪癖
• 在development stops时，每个图库都有自己需要更换的风险。

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

• 当单个对象图由来自不同容器的应用程序组件构成时，可能会出现复杂性。可能很难看到对象图并验证它们的正确性。
• 如果从两个容器中解析了某个组件，则可能会导致Torn Lifestyles

这并不是说你不应该在同一个解决方案或应用程序中拥有多个容器。例如，您可以将两个容器作为临时解决方案，因为您正在从一个库迁移到另一个库，但是大爆炸的迁移工作太多了。理想情况下，在这种情况下，你会在那时迁移一个应用程序，但即使这样也可能太多而无法立即咀嚼。

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

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