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

在Funq(在ServiceStack中使用)的情况下并非如此，因为它是一个静态绑定的IOC，更像是一个充满缓存构造函数委托的c#字典，而不是一个功能齐全的IOC。它以源代码形式包含在ServiceStack中，选择它是因为它非常快(即接近原生速度):http://www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP-NET.aspx

Funq中的注册是非侵入性的，即你必须手动注册你的依赖项，因为它不会不分青红皂白地扫描你的所有程序集，注册它找到的所有依赖项。如果你选择不使用Funq，而是通过注入IContainerAdapter并委托给另一个IOC来使用另一个IOC，那么你的Funq缓存委托字典将为空(即缓存丢失)，ServiceStack将简单地向你首选的IOC询问依赖项。

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

我会说——看情况。

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

如果你所有的依赖都是暂时的或者是通过自定义工厂方法创建的，那么你可能就没问题了。然而，一旦你开始尝试单例模式或"每个web请求一个实例"的依赖关系，事情可能会变得不可预测。

我以前从未使用过Funq，但如果它是一个有能力的IoC容器，我建议尽可能从你的项目中删除Ninject。除了消除应用程序难以跟踪bug的可能性之外，它还将使您的代码更加DRY和一致。

我不知道它将来是否会破裂，但它可能会。为了将风险降到最低，你可以尝试对你的注入例程进行单元测试，这样当你引入这些更改时，你就有了一种机制来确保你的注入例程仍然可以工作。

一般来说，我认为一致性可以提高质量，所以我会考虑重构代码以使用单个提供者。我使用Ninject，我有4个模块用于注入服务和存储库。每个模块包含10-20个注入例程——我可以在一个小时内重构它们。如果您的项目大小相似，则重构并使用单个IoC。

编辑我从未使用过ServiceStack。Net，但是您的项目对这个框架/工具包的依赖程度如何?你有可能在不久的将来用别的东西代替它吗?它是如何依赖于你的MVC项目?我正在设想这样一个场景:使用一个IoC的维护成本将高于使用另一个IoC的维护成本。

看Ninject，有Ninject和Ninject MVC 3扩展。扩展简化了工作，不与其他任何东西冲突。在我的情况下，我不得不用Ninject MVC 3取代标准的Ninject，因为对我来说，它做了标准版本所做的一切(+额外的)，并且更容易配置。