命名一个简单的依赖注入框架

Question

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

因此，对于.NET，是否有一个小的DI / IoC框架可以编译为单个DLL，除了标准库之外没有依赖关系，（如果需要）可以直接嵌入到使用它的程序集中，并强调基于代码/流利（而不是XML）的布线？它不能要求.NET framework 4.0。

Answer 1

我和你对IOC框架的看法非常相似。我一直都在使用IOC，我只是觉得不需要框架。

话虽如此，如果我选择一个，我会用AutoFac

它简单易用，手感轻巧。

Answer 2

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

Answer 3

您将要介绍的任何框架最终都会成为您应用的依赖项。此外，人们对轻量级的定义各不相同。看看Unity，或StructureMap或Castle Windsor，因为它们往往更受欢迎。 Scott Hanselman有一个完整的清单，here。随便挑选。

Answer 4

看看Ninject。

Answer 5

尝试StructureMap。

核心StructureMap.dll非常小。

Answer 6

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

Answer 7

我使用一个相当大的系统，我们手动注入了所有东西。我们利用抽象工厂模式来整理大部分注射/接线，结果很好。

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

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

• 如果您使用DI框架，则必须使用您的软件发布DI框架。对于某些人来说，这可能是一个显示阻止，其他人可能不得不争论额外依赖的优点。
• 您仍然需要构建构造函数以获取依赖性
• 你还需要告诉（或至少提示）DI框架使用什么。唯一的主要区别是你使用DI工厂而不是你自己的工厂。

至于构建该工厂，大多数重构工具只需很少的击键就能完成90％的工作。