如何选择DI容器？ [复制]答案

【问题标题】：How to choose a DI container? [duplicate]如何选择DI容器？ [复制]
【发布时间】：2012-03-15 11:02:06
【问题描述】：

可能重复：
How do the major C# DI/IoC frameworks compare?

有这么多 DI 容器，我感觉有点失落。我是 DI 模式的新手。

我正在阅读 Dependency Injection in .NET 这本书，我发现 DI 在改进代码库、使其松散耦合和更易测试方面非常有用。

我现在想为我的虚拟项目引入一个 DI 容器，但可供选择的实在太多了。

我应该如何在 Castle Windsor、Unity、StructureMap、Spring.NET、Autofac、Ninject、Funq、LinFu 等之间进行选择？

我想一个连贯的做法是“只选择一个”并开始使用它（因为我认为它们很容易互换，特别是在早期阶段），但我想做出更明智的决定。

【问题讨论】：

【解决方案1】：

.NET 开发最多的 DI 容器是Managed Extensibility Framework (MEF)，我强烈推荐使用它。 MEF 快速、简单且可在整个团队中维护，并具有完美的学习曲线。

【讨论】：

“用于 .NET 的最发达的 DI 容器是 MEF” - 这种笼统的说法肯定是不正确的
我刚刚分享了我的经验，我之前使用过一堆 DI 解决方案。没关系...
MEF 不是 DI 容器。 MEF 在基础实现之上提供即插即用配置。（顾名思义，它是一个可扩展性框架，而不是 DI）
-1 MEF 根本不是 DI 容器。
@ogggre 即使是 MEF 的开发人员也不声称它是一个容器。它是一种插件机制。您可能会滥用它作为容器。如果你喜欢用属性和诸如此类的东西来污染你的代码。您也可以使用锤子在墙上钻孔。

【解决方案2】：

除了其他出色的 cmets - 如果您安装 Unity.MVC3 包，请注意，如果您希望对象随每个请求一起处理，则必须使用 HierarchicalLifetimeManager。它工作得很好，但我认为在大多数情况下你会发现所有主要的都非常好。

你的问题是找到一个适合你的环境。有些地方允许开源，有些地方不允许，在这些情况下 Unity 胜出。

【讨论】：

【解决方案3】：

这就像买车一样。您可能喜欢丰田，但它只是 2.5 升发动机。你可能喜欢法拉利，但它太红了。你可能喜欢马自达，但你的老板不允许你开它。你可能喜欢悍马，但你的同事会嘲笑你。根据您的口味混合制造商，总会有人或在某个不同的时刻缺少一些东西。

我的看法是 - 首先，DI 通常比没有 DI 更好。选择任何东西，你会过得更好。我会选择：

我的 2 美分 - http://www.springframework.net/。我的意思是，他们的documentation contents page 有 20 页长……

或者您可能只是想查看类似问题的更多答案：

【讨论】：

【解决方案4】：

我一直在使用 Ninject 和 Unity。当你将 Unity MVC 添加到 Unity 时，代码让我想起了 Ninject 代码。

两者都很容易实现。两者都允许以启动器类为中心替换以配置文件为中心。

我建议创建一个 2 小时的项目，并在每个 ioc di 框架中实现它，并根据经验决定你喜欢哪一个。但是，如果您在不查看其他功能的情况下执行此操作，您可能会发现您遗漏了一些东西。因此，请查看外围功能，例如 3rd 方支持。

【讨论】：

【解决方案5】：

我的立场是，看几本——你已经得到了一本出色的“.NET 中的依赖注入”一书（我将在该列表中添加 Ninject，不幸的是本书中没有涉及）——然后选择其中一本它们是您最了解并喜欢语法的。开始使用高级功能并不重要，只要你开始。

一旦你有了一个 IoC 容器，替换它应该是微不足道的，因为你的所有更改都将集中在一个位置 - 聚合根 - 而不会分散在你的整个代码库中。如果您还没有使用 IoC 容器，还会迫使您设计依赖注入，这将对您的项目产生更大的影响。

【讨论】：

【解决方案6】：

您可以从 MVC3 中内置的 DependencyResolver 开始。稍后您可以轻松升级到 Enterprise Library Unity DI。

Brad Wilson 在How to use DI in MVC3 上提到了一系列帖子。

【讨论】：