我正在考虑在我们的用户界面中使用 Microsoft Unity 作为我的依赖注入工具。
我们的中间层已经在使用 Castle Windsor，但我认为我应该坚持使用 Microsoft。
有人对最好的依赖注入工具有什么想法吗？
【问题讨论】：
标签： .net dependency-injection inversion-of-control castle-windsor ioc-container
最近使用了其中的 6 个（Windsor、Unity、Spring.Net、Autofac、Ninject、StructureMap）我可以快速总结每一个，我们的选择标准和我们最终的选择。
注意：我们没有将 PicoContainer.Net 视为我们的团队之一，他们认为 .Net 端口与 Java 版本相比相当差。我们也没有关注 ObjectBuilder，因为 Unity 是在 ObjectBuilder2 之上构建的，默认情况下被认为是更好的选择。
首先，我可以说它们或多或少都非常相似，这实际上归结为最适合您的方法以及您的具体要求。我们的要求包括：
ILogger -> typeof(FileLogger) 或ILogger -> new FileLogger()）IDisposable容器拆解组件有据可查和/或在线信息随时可用
注意：虽然性能是一项要求，但在选择时并未将其考虑在内，因为根据benchmark
看来，所有审查过的容器都相似每个容器都用于一个典型的 Asp.Net webforms 项目（因为这是我们的目标应用程序类型）。我们使用带有单个简单用户控件的单个简单页面，每个控件分别继承自一个基本页面/基本控件。我们在BasePage 上使用 1 个容器作为“per request”范围容器，在 global.asax 上使用 1 个容器作为“应用程序”范围，并尝试将它们链接在一起，以便可以从两个容器中解决依赖关系。
每个 Web 应用程序共享一组人为的域对象，模拟多层次的依赖关系、范围类型（单例/瞬态）以及托管和非托管类（需要IDisposable）。 “顶级”依赖组件是从 BasePage 上的方法手动注入的。
Windsor - 满足所有标准并拥有良好的案例历史、博客社区和在线文档。易于使用，可能是事实上的选择。通过工厂设施创建高级组件。还允许链接单独创建的容器。
Spring.Net - 冗长且无用的文档以及不明显/易于可编程配置。不支持泛型。未选择
Ninject - 易于使用，文档清晰。强大的功能集可以满足我们的所有要求，但容器层次结构除外，因此很遗憾没有被选中。
StructureMap - 文档很少，虽然有一个非常高级的功能集可以满足我们的所有要求，但是没有用于容器层次结构的内置机制，尽管可以使用 for 循环一起破解参见 here lambda 表达式流式接口起初看起来确实有点过于复杂，但可以封装起来。
Unity - 有据可查、易于使用并符合我们所有的选择标准，并且有一个简单的扩展机制来添加我们需要的创建前/后创建事件机制。必须从父容器创建子容器。
Autofac - 有据可查且相对易于使用，虽然 lambda 表达式配置看起来确实有点过于复杂，但同样可以轻松封装。组件范围是通过“标记”机制实现的，并且所有组件都使用构建器预先配置，这有点不方便。子容器是从父容器创建的，并从“标签”分配组件。允许泛型注入。
我们最终的选择是在 Windsor 和 Unity 之间，而这一次我们选择了 Unity，因为它易于使用、文档、扩展系统以及处于“生产”状态。
【讨论】：
如果您的系统在设计时考虑了 IoC/DI，那么坚持使用一个容器并不是很重要。通过正确的方法，您可以轻松地更改 IoC 库。
当然，容器必须提供足够的灵活性来支持常见的广泛使用的场景（生命周期管理、适当的容器嵌套、XML 和代码配置、拦截、快速解析）。
我建议在 Castle（广泛使用并且有很多集成库）和 Autofac（轻量级、快速并且具有适当的容器嵌套，但没有那么广泛使用）之间进行选择
Hanselman 有一个comprehensive list of IoC containers
PS：你不想使用 Unity
【讨论】：
这是一篇比较 .NET IoC 容器的好文章。 http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/
【讨论】：
我一年前开始使用Autofac，从那以后就再也没有回头。
【讨论】：
我是 Autofac 的粉丝，但 Windsor 和 Unity 都会做得很好（尽管 Windsor 比 Unity 更有能力，并且不需要归因于您的代码）。不过，在系统中坚持使用单个容器有很多很好的非技术原因。
【讨论】：
使用有效的方法。大多数都具有他们独有的功能，并且几乎所有功能都比 Unity 更丰富。如果你只需要统一，你当然可以使用它。
仅仅因为它来自 Microsoft 而使用 Microsoft 的统一性是一种糟糕的决策方式。考虑一下您需要什么以及为什么，然后选择适合您需要的那个。
但是，如果可能的话，我赞同坚持使用单个容器的概念。
【讨论】：
我一直在使用Managed Extensibility Framework，发现它很容易使用。一直是integrated into .NET 4。
【讨论】：
除非您已经对某个可能的 IoC 容器解决方案所使用的特定子技术有经验和个人偏好，否则它们都运行良好，而且我看不到任何一个具有“杀手级功能”的人它从其他人中脱颖而出。 Unity 可能最适合已经使用 P&P Enterprise Library 4.x 的解决方案...
【讨论】：
IoC Container Benchmark - Performance comparison 有 20 多种产品的性能和特性比较表，并保持最新状态。
文章的结论：
SimpleInjector、Hiro、Funq、Munq 和 Dynamo 提供了最好的 性能，它们非常快。试试看！
尤其是Simple Injector 似乎是个不错的选择。速度很快，很好 文档，还支持拦截等高级场景 和通用装饰器。
【讨论】：