.net 您选择的DI容器有哪些其他人不具备的特性'；你没有吗？

对不起，这是一个很长的问题。我正在寻求对DI容器有足够热情的人的帮助，以便通读它。谢谢你抽出时间

这个问题的目标是列出一系列可以与DI容器进行比较的特性。（我不认为这是主观的，是吗？）我不是在问哪个容器更好。我想告诉我哪些功能是由一些DIs实现的，而不是其他的。这是一个非常具体的问题。

关于这一点，已经有很多话题，讨论了.NET的DI容器是最好的，以及选项是什么。这些问题中的大多数都是2009年的问题，自那时以来，DI容器的格局似乎发生了变化

现在别误会我。我坚信，选择哪个DI容器并不重要，只要您考虑一下并选择一个。顺便说一句，这不仅适用于DI容器，也适用于许多其他交叉关注点

然而，在一个组织内，最好确定一种特定的技术，这样开发人员就可以获得该技术的专业知识，并可以将其应用到整个项目中。这并不意味着上述技术应适用于所有项目。这仅仅意味着，如果一个项目没有令人信服的理由选择一个DI容器而不是另一个，那么就不会花时间讨论必须使用哪个容器，因为“首选”建议是预先设置的

如上所述，我正试图找出什么可以成为一个好的推荐。再次强调：不可能选择一种适合所有人的技术，但应该可以选择一种“默认”技术

这就引出了DI容器的比较标准。网络中有许多不同的DI容器。然而，有些人认为这是一个DI容器。尽管如此，这种表现可能很重要

将不同DI容器的一组比较标准放在一起，这是一个非常好的起点，但是有许多DI容器特性不在列表中。诸如支持AOP风格截取的能力和通过委托注册对象实例化的能力等特性立即浮现在脑海中。对容器层次结构的支持是列表中未提及的另一项功能，还有更多功能。对ASP.NET MVC的支持通常很容易添加，但如果它是开箱即用的或带有开箱即用的扩展，那就更好了

在撰写本文时，不同的DI容器已经不止一个了。在我看来，我大致将它们分类如下：

恐龙：

“恐龙”并不意味着“坏”。这意味着它们有很长的历史，因此非常成熟，可能具有现代特征，但核心是在.NET3.5出现之前开发的，这影响了它们的体系结构。它们都可以通过NuGet获得

林府：

• -林芙在我的脑海里被放在一边。与我的列表中提到的许多其他项目不同，这个项目没有看到很多最新版本。听起来好像作者已经放弃了这个项目，尽管我确信这不是真的
• -同一篇文章介绍了这个实验容器，它预编译对象实例化/注入代码，以便解析时间与根本不使用DI的时间相当。听起来很有趣，但我还没有听到任何关于产品使用的报告，而且（可能是我的错），这是我得到NuGet时唯一一个没有开箱即用的项目

现代版：

这些容器基于.NET3.5，不会给人任何“老化”的印象。团结有一个缺点，那就是设计过度。我不同意作者的观点，在Unity中使用装饰器的最简单方法是迟钝的，事实上，许多其他容器正是这样实现的。但我非常同意，无论何时，只要需要定制Unity来做一些它不是开箱即用的事情，这都是一个巨大的痛苦

LightCore看起来不错，速度快而且稳定，但是没有足够的文档，也不知道如何用它实现前面提到的decorator

所有这些都可以通过NuGet获得

极简主义：

• -功能数量有限，但易于设置且速度快
• -与Funq类似，但有线支持ASP.NET MVC和WCF
• -非常小的一个-适合一个.cs文件。灵活的基于lambda的注册，但其他功能不多
• -适用于Windows Phone 7的简约容器

其中一些可以通过NuGet获得

我从未听说过有人使用：

Scott Hanselman在列出不同的DI容器时提到了它们。我从来没有在其他场合见过他们

这些功能无法通过NuGet获得

另一个标准是商业支持的可用性。我明白Castle.Windsor是有空的，但我想这就是问题所在。Ninject在上提到了付费支持，但没有提供电子邮件或链接，而且由于这种支持很可能没有一家成熟公司的支持，因此可能不可靠

我目前的想法是，温莎城堡很有吸引力，因为它成熟且有商业支持。Unity很有吸引力，因为它由Microsoft备份（尽管不受支持）。Autofac和Ninject在现代、易用、易扩展和易理解的部门很有吸引力，Ninject在易入门类别中获胜

现在，把这件事弄清楚，我们接近我真正的问题了。为了能够选择一个DI容器而不是另一个，需要有比较标准。明显的是支持功能。信诺