4

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

我在项目开始时就开始使用 Ninject 进行 DI。现在我正在将 ServiceStack 添加到组合中，我很好奇是否有任何未来问题的可能性：

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

4

3 回答 3

1

在 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 更像是依赖项的存储库。

于 2011-10-11T14:03:01.220 回答
0

我会说 - 这取决于。

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

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

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

于 2011-10-11T12:24:41.420 回答
0

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

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

编辑 我从未使用过 ServiceStack.Net，但您的项目对这个框架/工具包的依赖程度如何？您是否可能在不久的将来用其他东西代替它？它对您的 MVC 项目的依赖程度如何？我正在尝试考虑使用一个 IoC 的维护成本将高于使用另一个 IoC 的维护成本的场景。

查看 Ninject，有 Ninject 和 Ninject MVC 3 扩展。扩展简化了工作并且不与其他任何冲突。就我而言，我不得不用 Ninject MVC 3 替换标准 Ninject，因为对我来说它完成了标准版本所做的一切（+ 额外）并且更易于配置。

于 2011-10-11T12:13:55.853 回答