Ninject vs Unity for DI [关闭]

我们正在使用ASP.net MVC。

以下哪个是最好的DI框架Ninject或Unity？为什么？

上次查看它们中的任何一个时，我发现Ninject略好一些。但是两者都有缺点。

Ninject具有更好的流利配置方案。Unity似乎主要依靠XML配置。Ninject的主要缺点是它要求您在代码的任何地方引用Ninject.Core来添加[Inject]属性。

如果我要问的话，为什么将您的选择限制在这两个范围内？我认为Castle.Windsor，Autofac和StructureMap至少一样好或更好。

我知道这是一个老问题，但这是我的想法：

我个人喜欢Ninject。我喜欢流畅的界面并避免使用XML。我通常喜欢XML，只是不喜欢这种配置。特别是在涉及重构时，流畅的界面使其更易于纠正。

我想念StructureMap的ObjectFactory，但是有一些简单的解决方法可将其添加到Ninject。

正如Jeffery指出的，当您只有一个构造函数时，不必使用[Inject]属性。

我发现我更喜欢流利的接口，不仅因为它们避免使用XML，还因为当我更改影响它们的内容时，它们会导致编译时错误。XML配置没有，我记住的越少更改就越好。

如果您使用注入构造器而不是Unity，则Ninject会检测循环依赖关系，而与Unity无关，无论注入技术如何，都只会抛出一个StackOverflowException，这很难调试。

我同意Mendelt的观点，没有“最佳”的DI框架。这只是取决于情况，他们各有利弊。想想大卫·海顿（David Hayden）在DotNet Rocks上说，如果您使用EntLib的其余部分并且对此很熟悉，那么Unity是首选。我个人使用Unity是因为我的客户喜欢这样的事实：如果您理解我的意思，它会在DLL上显示Microsoft Enterprise Library（Unity）。

我既使用xml配置来设置接口，又使用它们的具体实现，但是随后在注入时在代码中使用属性，例如：

<type type="ILogger" mapTo="EntLibLogger">
   <lifetime type="singleton"/>
</type>

并在代码中：

[InjectionConstructor]
public Repository([Dependency] ILogger logger)

我个人认为这样做可以使事情更清楚，但是当然可以说您将在整个应用程序中引用统一性。由你决定。

http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison

团结更快，但不是最好的