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

时间:2011-10-11 11:59:59

标签: c# asp.net asp.net-mvc asp.net-mvc-3 servicestack

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

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

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

3 个答案:

答案 0 :(得分: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更像是依赖存储库。

答案 1 :(得分:0)

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

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

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

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

答案 2 :(得分:0)

我会说 - 这取决于。

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

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

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