在解决方案中有多个IoC容器是否存在问题？

Question

我正在构建一个带有ASP.NET MVC前端和ServiceStack.NET Web服务的多层应用程序。

我在项目开始时就开始使用Ninject进行DI。既然我正在将ServiceStack添加到组合中，我很好奇，如果将来有任何潜在的问题：

ServiceStack Library默认使用Funq作为其IoC容器。一切似乎都正常工作，但我想知道在同一个应用程序中有两个IoC容器是否会出现任何问题？

Answer 1

并非真的在Funq（在ServiceStack中使用）作为其静态绑定的IOC，它更像是一个充满缓存构造函数委托的C＃字典，而不是一个功能齐全的IOC。它被包含在ServiceStack中的源表单中，因为它非常快（即接近本机速度）而被选中： http://www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP-NET.aspx

Funq中的注册是非侵入性的，即您必须手动注册依赖项，因为它不会无差别地扫描注册所有依赖项的所有程序集。如果您选择不使用Funq并使用另一个IOC by injecting an IContainerAdapter并委托给另一个IOC，那么缓存委托的Funq词典将为空（即缓存未命中），而ServiceStack将简单地向您的首选IOC请求依赖。< / p>

唯一要记住的是，Web服务本身是由ServiceStack注册和自动连接的，而不是您首选的IOC容器，因此在这种情况下，您的IOC更像是依赖存储库。

Answer 2

我不知道它将来是否会破裂，但可能会。为了最大限度地降低风险，您可以尝试对注射程序进行单元测试，然后在引入更改时，您将拥有一种机制来确保注射程序仍然有效。

通常，我认为一致性可以提高质量，因此我会考虑重构代码以使用单个提供程序。我使用Ninject，我有4个模块用于注入服务和存储库。每个模块包含10-20个注射程序 - 我可以在一小时内重构这些程序。如果你的项目大小相同，那么重构并使用一个IoC。

修改 我从未使用过ServiceStack.Net，但您的项目依赖于此框架/工具包？您是否有可能在不久的将来用其他东西替换它？它对你的MVC项目有多依赖？我试图想一个使用一个IoC的维护成本高于使用另一个IoC的维护成本的情况。

看看Ninject，有Ninject和Ninject MVC 3扩展。扩展简化了工作，不会与其他任何东西发生冲突。在我的情况下，我不得不用Ninject MVC 3替换标准的Ninject，因为对我而言，它完成了标准版本所做的一切（+额外）并且更容易配置。

Answer 3

我会说 - 这取决于。

如果你使用的IoC框架有不同的依赖关系，没有重叠，那么我没有看到任何问题。如果我怀疑，你实际上不得不加倍你的IoC注册，那么我想这取决于你如何管理依赖项的生命周期。

如果所有依赖项都是瞬态的或通过自定义工厂方法创建，那么您可能会没问题。但是，一旦你开始尝试将单例或“每个Web请求实例”依赖项放入混合中，事情可能会变得无法预测。

我之前从未使用过Funq，但如果它是一个功能强大的IoC容器，我建议如果可能的话，从项目中删除Ninject。除了消除您的应用程序难以跟踪错误的前景，它将使您的代码更加干燥和一致。