我正在开发一个项目，该项目使用其他一些开发人员提供的一组库，这些库使用 structuremap作为 IoC 容器。 [我有代码库]
我们合并这些库的应用程序使用 unity container .
在同一个解决方案中使用两个容器框架有缺点吗？我想将所有内容移至同一个 IoC 容器，但如何证明额外工作的合理性？
最佳答案
在同一个解决方案中拥有多个容器库与在同一个应用程序中拥有多个容器库之间存在差异，因为一个解决方案可以由多个可运行的应用程序组成。
所有组件都应连接到应用程序的启动路径，即 Composition Root :
A Composition Root is a (preferably) unique location in an application where modules are composed together.
与构造函数注入(inject)一起使用，组合根模式使您的应用程序完全松散耦合，并使您的应用程序代码与 DI 容器解耦。
根据组合根模式，应用程序的任何其他部分都不应依赖于 DI 容器。事实上，您使用的库确实存在问题，因为这会迫使您进入某个 DI 容器。更好的解决方案是使库 DI-friendly .
在同一个解决方案中使用多个容器库有一些缺点:
- 您必须学习两个不同的 DI 容器库，每个库都有其局限性和怪癖
- 每个库都有其自身的风险，在 development 时需要更换。 stops .
除此之外，在同一个应用程序中使用多个容器库还有一些缺点:
- 当单个对象图由来自不同容器的应用程序组件构建时，可能会出现复杂性。可视化对象图并验证它们的正确性可能很困难。
- 如果某个组件从两个容器中解析，可能会导致 Torn Lifestyles
这并不是说您永远不应该在同一个解决方案或应用程序中拥有多个容器。例如，您可以使用两个容器作为临时解决方案，因为您要从一个库迁移到下一个库，但大爆炸式迁移的工作量太大。理想情况下，在这种情况下，您可以一次迁移一个应用程序，但即使如此，也可能会难以一次性完成。
另一个常见场景是，当您运行的应用程序框架在内部使用 DI 容器来构建其服务时，拥有两个容器就可以了。这些框架的常见示例是 ASP.NET Core 和 NServiceBus。在这种情况下，为了清楚地区分，我通常谈论框架的配置系统而不是其内部容器，因为这就是它的本质。它是一个容器，是一个实现细节。
在这种情况下，您可以按原样保留内置“配置系统”来解析框架组件，并使用您选择的 DI 容器来构建应用程序组件的对象图.
关于c# - 在 .NET 的同一解决方案中使用两个 IoC 容器的缺点？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50474299/