我应该使用哪种依赖注入工具？

Question

我正在考虑在用户界面中使用Microsoft Unity作为我的依赖注入工具。

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

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

• Autofac
• Castle MicroKernel/Windsor
• PicoContainer.NET
• Puzzle.NFactory
• Spring.NET
• StructureMap
• Ninject
• Unity
• Simple Injector
• NauckIT.MicroKernel
• WINTER4NET
• ObjectBuilder

Answer 1

最近匆匆使用其中的6个（Windsor，Unity，Spring.Net，Autofac，Ninject，StructureMap）I可以提供每个的快速摘要，我们的选择标准和我们的最终选择。

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

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

要求

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

• 随时可用的文件和/或在线信息

  注意：虽然性能是一项要求，但在选择中没有考虑因素，因为根据此benchmark

，所有审核的容器似乎都相似

测试

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

每个Web应用程序共享一组设计的域对象，模拟多级依赖关系，范围类型（​​单例/瞬态）以及托管和非托管类（需要IDisposable）。 “顶级”依赖项组件是从BasePage上的方法手动注入的。

结果

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

Spring.Net - 详细和无用的文档，并且没有明显/易于编程的配置。不支持泛型。未选择

Ninject - 易于使用，具有良好的清晰文档。强大的功能集满足了除容器层次结构之外的所有要求，因此不幸的是没有选择。

StructureMap - 文档记录很少，虽然有相当高级的功能集满足了我们的所有要求，但是没有内置的容器层次结构机制，尽管可以使用for循环一起攻击，参见here lambda表达式流畅的界面起初看起来有点复杂，虽然可以封装起来。

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

Autofac - 记录良好且相对容易使用，虽然lambda表达式配置似乎有点过于复杂，但是，再次，可以很容易地封装掉。组件范围是通过“标记”机制实现的，所有组件都是使用构建器预先配置的，这有点不方便。子容器是从父级创建的，并从“标记”分配了组件。允许通用注射。

结论

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

Answer 2

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

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

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

Hanselman有一个comprehensive list of IoC containers

PS：你不想使用Unity

Answer 3

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

Answer 4

我一年前开始使用Autofac并且从那以后就没有回头了......

Answer 5

我是一个Autofac粉丝，但Windsor和Unity都会做得很好（虽然Windsor比单位更有能力而且不需要归因于你的代码）。但是，在系统中粘贴单个容器有很多非技术性的原因。

Answer 6

使用有效的方法。大多数都具有独特的功能，几乎所有功能都比Unity更丰富。如果团结就是你所需要的，你当然可以使用它。

使用微软的统一只是因为它来自微软是一个很难做出决定的方式。想想你需要什么和为什么，并选择适合你需求的那个。

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

Answer 7

我一直在使用Managed Extensibility Framework，发现它很容易使用。这是integrated into .NET 4。

Answer 8

https://stackoverflow.com/questions/71041/which-single-iocdi-container-would-you-recommend-using-and-why

Answer 9

除非您已经拥有一种可能的IoC容器解决方案所使用的特定子技术的经验和个人优势，否则它们都运行良好，我没有看到任何特别具有“杀手功能”的任何一种它从其他人中脱颖而出。 Unity可能最适合已经使用P＆amp; P企业库4.x ...

的解决方案

Answer 10

IoC Container Benchmark - Performance comparison包含20多种产品的性能和功能比较表，并使其保持最新状态。

文章的结论：

  

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

     

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