38

我正在考虑在我们的用户界面中将 Microsoft Unity 用于我的依赖注入工具。

我们的中间层已经在使用 Castle Windsor，但我认为我应该坚持使用 Microsoft。

有人对最好的依赖注入工具有什么想法吗？

4

9 回答 9

61

最近增加了其中 6 种（Windsor、Unity、Spring.Net、Autofac、Ninject、StructureMap）的使用率，我可以提供一个快速总结，包括我们的选择标准和最终选择。

注意：我们没有考虑 PicoContainer.Net，因为我们的团队之一认为 .Net 端口与 Java 版本相比非常差。我们也没有研究 ObjectBuilder，因为 Unity 是在 ObjectBuilder2 之上构建的，默认情况下被认为是更好的选择。

首先，我可以说它们或多或少都非常相似，这真的归结为最适合你的东西，以及你的具体要求。我们的要求包括：

要求

  • 基于构造函数的注入（我们不打算使用属性、字段或方法注入）
  • 可编程配置（不是XML）
  • 容器层次结构（每个应用程序、每个请求和每个会话一个，以更隐式地将组件生命周期范围绑定到容器）
  • 组件生命周期管理（用于更精细的范围界定，例如瞬态/单例）
  • 从接口注入到类型或具体实例（例如ILogger -> typeof(FileLogger)或ILogger -> new FileLogger()）
  • 用于预/后初始化的高级组件创建/“创建事件机制”
  • 正确处理IDisposable容器拆解上的组件

  • 有据可查和/或在线信息随时可用

    注意：虽然性能是一项要求，但并未将其纳入选择因素，因为根据此基准，所有审查的容器似乎都相似

测试

每个容器都用于典型的 Asp.Net webforms 项目（因为这是我们的目标应用程序类型）。我们使用带有单个简单用户控件的单个简单页面，每个控件分别继承自一个基本页面/基本控件。我们在BasePage“每个请求”范围容器上使用了 1 个容器，在 global.asax 上使用 1 个容器作为“应用程序”范围，并尝试将它们链接在一起，以便可以从两个容器中解决依赖关系。

每个 Web 应用程序共享一组人为的域对象，模拟多层次的依赖关系、范围类型（​​单例/瞬态）以及托管和非托管类（IDisposable必需）。“顶级”依赖组件是从BasePage.

结果

Windsor - 满足所有标准，并拥有良好的案例历史、博客社区和在线文档。易于使用，可能是事实上的选择。通过工厂设施创建高级组件。还允许链接单独创建的容器。

Spring.Net - 冗长且无用的文档以及不明显/易于可编程配置。不支持泛型。未选择

Ninject - 易于使用，文档清晰。强大的功能集满足了我们所有的要求，除了容器层次结构，所以很遗憾没有选择。

StructureMap - 记录不充分，虽然有一个满足我们所有要求的相当高级的功能集，但是没有用于容器层次结构的内置机制，尽管可以使用 for 循环一起破解，请参见此处 lambda 表达式流利的接口似乎有点过头了起初很复杂，尽管可以封装起来。

Unity - 有据可查，易于使用，符合我们所有的选择标准，并且有一个简单的扩展机制来添加我们需要的创建前/后创建事件机制。必须从父容器创建子容器。

Autofac - 有据可查且相对易于使用，尽管 lambda 表达式配置似乎有点过于复杂，但同样可以轻松封装。组件范围是通过“标记”机制实现的，并且所有组件都使用构建器预先配置，这有点不方便。子容器是从父容器创建的，并从“标签”分配组件。允许通用注入。

结论

我们最终的选择是在 Windsor 和 Unity 之间，而这一次我们选择了 Unity，因为它易于使用、文档、扩展系统以及处于“生产”状态。

于 2008-12-06T15:37:46.053 回答
12

如果您的系统在设计时考虑了 IoC/DI，那么坚持使用一个容器并不是很重要。通过正确的方法，您可以轻松地更改 IoC 库。

当然，容器必须提供足够的灵活性来支持常见的广泛使用的场景（生命周期管理、适当的容器嵌套、XML 和代码配置、拦截、快速解析）。

我建议在 Castle（广泛使用并且有很多集成库）和 Autofac（轻量级、快速并且具有适当的容器嵌套，但不是那么广泛使用）之间进行选择

Hanselman提供了一份 IoC 容器的完整列表

PS：你不想使用 Unity

于 2008-09-30T06:00:01.500 回答
12

这是一篇比较 .NET IoC 容器的好文章。 http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/

于 2008-10-03T20:36:06.680 回答
5

我一年前开始使用Autofac，从那以后就再也没有回头。

于 2009-07-15T22:03:49.973 回答
4

我是 Autofac 的粉丝，但 Windsor 和 Unity 都会做得很好（尽管 Windsor 比 Unity 更有能力，并且不需要归因您的代码）。但是，在系统中坚持使用单个容器有很多很好的非技术原因。

于 2008-09-29T14:33:54.783 回答
2

使用有效的方法。大多数都具有他们独有的功能，并且几乎所有功能都比 Unity 更丰富。如果你只需要统一，你当然可以使用它。

仅仅因为它来自微软就使用微软的统一性是一种糟糕的决策方式。考虑一下您需要什么以及为什么，然后选择适合您需要的那个。

但是，如果可能的话，我赞同坚持使用单个容器的概念。

于 2008-09-29T14:36:48.927 回答
2

我一直在使用Managed Extensibility Framework，发现它很容易使用。它已集成到 .NET 4中。

于 2010-02-02T20:58:02.477 回答
0

除非您已经对可能的 IoC 容器解决方案之一所使用的特定子技术有经验和个人偏好，否则它们都运行良好，我看不出有任何一个特别具有使其脱颖而出的“杀手级功能”从其他人。Unity 可能最适合已经使用 P&P Enterprise Library 4.x 的解决方案...

于 2008-11-15T22:11:49.947 回答
0

IoC Container Benchmark - 性能比较具有 20 多种产品的性能和功能比较表，并保持最新。

文章的结论：

SimpleInjector、Hiro、Funq、Munq 和 Dynamo 提供了最好的性能，它们非常快。试试看！

特别是Simple Injector似乎是一个不错的选择。它非常快，有很好的文档，还支持拦截和通用装饰器等高级场景。

于 2013-02-22T06:03:23.297 回答