命名一个简单的依赖注入框架[关闭]答案

【问题标题】：Name a simple Dependency Injection framework [closed]命名一个简单的依赖注入框架[关闭]
【发布时间】：2011-03-27 23:33:07
【问题描述】：

我想在一个小型但不断发展的项目中首次尝试使用 DI/IoC 框架，并且我不想通过引入庞大的依赖项来过多地干扰项目。该项目本身的部分目的是用作其他项目中的库，我不想让用户管理额外的依赖项。这也是一个品味问题——我觉得组件的大小应该与我实际需要的服务数量成正比。我讨厌将一个庞大的组件与它自己的依赖项结合起来，只使用它的一小部分。

那么，对于 .NET，是否有一个小型 DI/IoC 框架可以编译成一个 DLL，除了标准库之外没有依赖项，（如果需要）可以直接嵌入到使用它的程序集中，并且强调基于代码/流畅（相对于 XML）的布线？它必须不需要 .NET 框架 4.0。

【问题讨论】：

如果你只想要控制反转，你根本不需要库。只需通过类的构造函数注入依赖项即可。
现在这就是我正在做的事情。然而，连接起来开始变得有点麻烦，我知道随着项目的发展它会变得更糟。（这是一个由许多组件组成的编译器项目，应该可以将组件换成其他组件......）
我同意罗伯特的观点。通过在代码中注入依赖项，您也可以获得编译器的好处。我通常在 Main() 方法中连接我的应用程序。

标签： c# .net frameworks dependency-injection

【解决方案1】：

看看Ninject。

【讨论】：

在ninject.org/download 下载的 .NET Framework 3.5 包含 6 个超过半兆的 DLL，比我希望的要重。
您在项目中引用的只是单个 Ninject.dll 程序集，它确实符合您的轻量级标准。如果您需要，还有一组 Extensions 和 Web.Mvc 程序集可添加到基本 NInject 功能中。
这些程序集是可选的，还是 Ninject.dll 需要它们？是否需要 XML 文件？
未接受 - 文档处于混乱状态（如果不了解概念，查看源代码无济于事......我迷失在“绑定”、“组件”的网络中、“内核”、“计划者”和“设置”）。而且……
...此外，它很慢。给定一个空的“INothing”接口、一个“Nothing”类和一个简单的绑定，一个调用 kernel.Get() 的紧密循环在我的 Release 版本中每秒只能生成 36,000 个对象。相反，仅调用“globalVariable = new Nothing()”每秒就会产生 105,000,000 个对象（大约快 3,000 倍）。他们可能会使用 Lightweight Codegen 进行实际的构造函数调用，但构造函数调用开销与如此多的检查、LINQ 查询、抽象层、方法调用和 Ninject 制作的临时对象相比相形见绌。

【解决方案2】：

我对 IOC 框架的看法与您大致相同。我一直都在使用 IOC，只是觉得对框架的需求不大。

话虽如此，如果我要拿起一个，我会使用AutoFac

它简单、容易掌握，而且感觉很轻。

【讨论】：

nblumhardt.com/2010/04/introducing-autofac-2-1-rtw - 表示“Autofac 使用 .NET 4.0 中的底层支持”
对，AutoFac 2.1 可以。但是之前的版本（1.4）不需要4.0。如果您正在部署一个 4.0 应用程序，那么它使用底层 .Net 东西的事实是一件好事 :)
我仅限于 VS 2008，此外，不想要求用户升级他们的 .NET 框架。似乎有一个 .NET 3.5 版本的 AutoFac 2.2，但它带有 5 个 DLL 和一个比 5 个 DLL 加起来还大的 XML 文件，我想知道这需要多少？
我刚刚注意到，Ninject 和 AutoFac 的 XML 文件都比它们的主 DLL 大得多......编辑：哈哈！我明白了，XML 文件只包含文档。所以它们在运行时实际上并不是必需的，好消息。
您只需要Autofac.dll，它完全适用于.Net 3.5

【解决方案3】：

除了 NInject 之外，我还建议您查看 Microsoft 的 DI 框架，Unity。

【讨论】：

【解决方案4】：

试试StructureMap。

核心StructureMap.dll 非常小。

【讨论】：

【解决方案5】：

我使用的是一个相当大的系统，我们手动注入了所有内容。我们利用抽象工厂模式来整理大部分的注入/布线，效果很好。

DI 框架非常丰富。在承担额外的外部依赖之前，请花一些时间考虑应用不同/新模式是否可以解决您的问题。

编辑：（可能有偏见/不公正）我没有使用 DI 框架的原因：

如果您使用 DI 框架，则必须将 DI 框架与您的软件一起提供。这对某些人来说可能是个噱头，而其他人可能不得不争论额外依赖的优点。
您仍然需要构建构造函数来获取依赖项
您仍然必须告诉（或至少提示）DI 框架使用什么。唯一的主要区别是您使用的是 DI 工厂而不是您自己的工厂。

至于构建工厂，大多数重构工具只需很少的按键就可以为您完成 90% 的工作。

【讨论】：

你真的用过DI框架吗？如果是这样，您是否觉得麻烦多于其价值？
我没有看到在大型系统中手动注入比使用 DI 框架自动完成工作量更少。
评论的回复有点长，改为编辑我的答案。

【解决方案6】：

您将引入的任何框架最终都会成为您应用的依赖项。此外，人们对什么是轻量级有不同的定义。看看Unity、StructureMap 或温莎城堡，因为它们往往更受欢迎。 Scott Hanselman 有一个完整的列表，here。任君挑选。

【讨论】：

+1 表示列表。从技术上讲，如果我将 IoC 容器嵌入到我的一个 DLL 中并更改命名空间，它看起来不会像外部的依赖项，而且我可以选择删除我不使用的任何内容。鉴于他们如何解释其设计，我认为 (Windsor) MicroKernel 适合这种方法......
引用 Hanselman 帖子底部的 @Qwertie 是 15 行代码中两个 IoC 容器的链接。当您不需要“框架”时，它们的目的是非常轻量级。也许值得研究。

【解决方案7】：

examples on the web 关于编写自己的容器，尽管它们非常基础，并且缺少更强大的框架提供的功能。

【讨论】：