解决方案中使用多个 IoC 容器是否存在问题？
我正在使用 ASP.NET MVC 前端和 ServiceStack.NET Web 服务构建一个多层应用程序。
我在项目开始时就开始使用 Ninject 进行 DI。现在我将 ServiceStack 添加到其中，我很好奇未来是否存在任何潜在问题：
ServiceStack 库默认使用 Funq 作为其 IoC 容器。一切似乎都正常工作，但我想知道在同一个应用程序中使用两个 IoC 容器是否会出现任何问题？
I am building a multi-layer app with with an ASP.NET MVC front-end, and ServiceStack.NET web services.
I began using Ninject for DI at the start of the project. Now that I am adding ServiceStack into the mix I am curious if there is any potential for future problems:
The ServiceStack Library uses Funq as its IoC container by default. Everything seems to be working normally, but I am wondering if I will see any issues with having two IoC containers in the same application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
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 更像是依赖项存储库。
Not really in the case of Funq (which is used in ServiceStack) as its a statically bound IOC which is more like a C# Dictionary full of cached constructor delegates than an full-featured IOC. It is included in source form in ServiceStack and was chosen because it is very fast (i.e. near native speeds):
http://www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP-NET.aspx
The registration in Funq is non-invasive i.e. you have to manually register your dependencies as it doesn't indiscriminately scan all your assemblies registering all dependencies it finds. If you choose not to use Funq and use another IOC by injecting an IContainerAdapter and delegating to another IOC, then your Funq dictionaries of cached delegates will be empty (i.e. cache miss) and ServiceStack will simply ask your preferred IOC for the dependency instead.
The only thing to keep in mind is, the Web Services themselves are registered and auto-wired by ServiceStack and not your preferred IOC container, so in this case your IOC acts more like a repository of dependencies.
我想说——这要看情况。
如果您使用的 IoC 框架具有不同的依赖关系且没有重叠，那么我看不到任何问题。如果正如我怀疑的那样，您实际上必须将 IoC 注册加倍，那么我想这取决于您如何管理依赖项的生命周期。
如果您的所有依赖项都是暂时的或通过自定义工厂方法创建的，那么您可能会没问题。然而，一旦您开始尝试将单例或“每个网络请求实例”依赖项混入其中，事情很可能会变得不可预测。
我以前从未使用过 Funq，但如果它是一个功能强大的 IoC 容器，我建议尽可能从您的项目中删除 Ninject。除了消除应用程序难以跟踪错误的可能性之外，它还将使您的代码更加干燥和一致。
I would say - it depends.
If the IoC frameworks you're using have different dependencies with no overlap then I don't see any issues. If as I suspect though, you're effectively having to double-up your IoC registrations then I guess it depends on how you're managing the lifetime of your dependencies.
If all your dependencies are transient or created through custom factory methods then you'll probably be OK. However things may well get unpredictable once you start trying to throw singletons or 'instance per web request' dependencies into the mix.
I've never used Funq before, but if it's a capable IoC container I'd recommend removing Ninject from your project if possible. Aside from eliminating the prospect of your application having hard to track bugs, it will keep your code much more DRY and consistent.
我不知道它将来是否会破裂，但有可能。为了最大限度地降低风险，您可以尝试对注入例程进行单元测试，这样当您引入更改时，您将拥有一种机制来确保您的注入例程仍然有效。
一般来说，我认为一致性可以提高质量，因此我会考虑重构代码以使用单个提供程序。我使用 Ninject，并且有 4 个用于注入服务和存储库的模块。每个模块包含 10-20 个注入例程 - 我可以在一小时内重构这些例程。如果您的项目大小相似，请重构并使用单个 IoC。
编辑
我从未使用过ServiceStack.Net，但是您的项目对这个框架/工具包的依赖程度如何？您可能会在不久的将来用其他东西取代它吗？它对您的 MVC 项目的依赖程度如何？我正在尝试考虑一种场景，其中使用一个 IoC 的维护成本将高于使用另一个 IoC 的维护成本。
看一下 Ninject，有 Ninject 和 Ninject MVC 3 扩展。该扩展简化了工作并且不会与其他任何内容发生冲突。就我而言，我必须用 Ninject MVC 3 替换标准 Ninject，因为对我来说它完成了标准版本所做的一切（+额外）并且更容易配置。
I don't know whether it'll break in the future, but it might. To minimise the risk, you could try unit-testing your injection routines, so then when you introduce the changes you'll have a mechanism to ensure that your injection routines still work.
Generally, I think that consistency improves quality, so I would consider refactoring code to use a single provider. I use Ninject and I have 4 modules for injecting services and repositories. Each module contains 10-20 injection routines - I can refactor these within an hour. If your project is of similar size, then refactor and use a single IoC.
Edit
I have never used ServiceStack.Net, but how dependent is your project on this framework/toolkit? Are you likely to replace it with something else in near future? How dependent is it on your MVC project? I'm trying to think of a scenario where maintenance cost of using one IoC will be higher than maintenance cost of using another IoC.
Looking at Ninject, there is Ninject and Ninject MVC 3 extension. The extension simplifies the job and doesn't conflict with anything else. In my case, I had to replace standard Ninject with Ninject MVC 3 because for me it did everything the standard version did (+ extra) and was easier to configure.