Last time I looked at either of them I found Ninject slightly better. But both have their drawbacks.
Ninject has a better fluent-configuration scheme. Unity seems to rely mostly on XML configuration. Ninject's main drawback is that it requires you to reference Ninject.Core everywhere in your code to add [Inject] attributes.
If I may ask, why are you limiting your choices to these two? I think Castle.Windsor, Autofac and StructureMap are at least as good or better.
我发现我更喜欢流畅的界面，不仅因为它们避免了 XML，而且因为当我更改影响它们的内容时，它们会导致编译时错误。 XML 配置则不然，而且我需要记住的更改越少，我的情况就越好。
I know this is an old question, but here are my thoughts:
I personally like Ninject. I like the fluent interfaces and avoiding of XML. I generally like XML, just not for this kind of config stuff. Especially when refactoring is involved the fluent interfaces make it easier to correct.
I miss StructureMap's ObjectFactory, but there are easy workarounds to add that to Ninject.
As Jeffery points out you don't have to use the [Inject] attribute when you only have one constructor.
I found that I prefer the fluent interfaces not only because they avoid XML, but because they cause compile time errors when I change something that affected them. The XML configuration doesn't and the less I have to remember to change the better off I am.
Ninject detects circular dependencies if you use Injection Constructors as opposed to Unity that regardless of the injection technique just throws a StackOverflowException which is extremely hard to debug.
I agree with Mendelt, there is no "best" DI framework. It just depends on the situation and they all have pros and cons. think David Hayden said on DotNet Rocks that Unity is the preferred choice if you use the rest of EntLib and are familiar with that. I personally use Unity because my customer likes the fact that it says Microsoft Enterprise Library (Unity) on the DLLs, if you get what I´m saying.
I use both both xml configuration for setting up the interfaces and their concrete implementations but then I use attributes in code when injecting, like:
[InjectionConstructor]
public Repository([Dependency] ILogger logger)
Personally I think that makes it clearer what happens, but of course one could argue that you will have references to unity all over your application. It´s up to you.
发布评论
评论（5）
上次我查看它们中的任何一个时，我发现 Ninject 稍微好一些。 但两者都有其缺点。
Ninject 有更好的流畅配置方案。 Unity 似乎主要依赖于 XML 配置。 Ninject 的主要缺点是它要求您在代码中的任何地方引用 Ninject.Core 来添加 [Inject] 属性。
如果我可以问，你为什么将你的选择限制在这两个？ 我认为 Castle.Windsor、Autofac 和 StructureMap 至少同样好或更好。
Last time I looked at either of them I found Ninject slightly better. But both have their drawbacks.
Ninject has a better fluent-configuration scheme. Unity seems to rely mostly on XML configuration. Ninject's main drawback is that it requires you to reference Ninject.Core everywhere in your code to add [Inject] attributes.
If I may ask, why are you limiting your choices to these two? I think Castle.Windsor, Autofac and StructureMap are at least as good or better.
我知道这是一个老问题，但这是我的想法：
我个人喜欢 Ninject。 我喜欢流畅的界面并避免使用 XML。 我通常喜欢 XML，只是不喜欢这种配置内容。 特别是当涉及重构时，流畅的界面使其更容易纠正。
我怀念 StructureMap 的 ObjectFactory，但是有一些简单的解决方法可以将其添加到 Ninject。
正如 Jeffery 指出的那样，当您只有一个构造函数时，不必使用 [Inject] 属性。
我发现我更喜欢流畅的界面，不仅因为它们避免了 XML，而且因为当我更改影响它们的内容时，它们会导致编译时错误。 XML 配置则不然，而且我需要记住的更改越少，我的情况就越好。
I know this is an old question, but here are my thoughts:
I personally like Ninject. I like the fluent interfaces and avoiding of XML. I generally like XML, just not for this kind of config stuff. Especially when refactoring is involved the fluent interfaces make it easier to correct.
I miss StructureMap's ObjectFactory, but there are easy workarounds to add that to Ninject.
As Jeffery points out you don't have to use the [Inject] attribute when you only have one constructor.
I found that I prefer the fluent interfaces not only because they avoid XML, but because they cause compile time errors when I change something that affected them. The XML configuration doesn't and the less I have to remember to change the better off I am.
如果您使用注入构造函数而不是 Unity，Ninject 会检测循环依赖关系，无论注入技术如何，都会抛出 StackOverflowException，这非常难以调试。
Ninject detects circular dependencies if you use Injection Constructors as opposed to Unity that regardless of the injection technique just throws a StackOverflowException which is extremely hard to debug.
我同意 Mendelt 的观点，没有“最好的”DI 框架。 这取决于具体情况，它们都有优点和缺点。 想想 David Hayden 在 DotNet Rocks 上说的，如果您使用 EntLib 的其余部分并且熟悉它，Unity 是首选。 我个人使用 Unity，因为我的客户喜欢它在 DLL 上显示 Microsoft Enterprise Library (Unity)（如果您明白我的意思的话）。
我同时使用 xml 配置来设置接口及其具体实现，但随后我在注入时在代码中使用属性，例如：
和在代码中：
就我个人而言，我认为这可以更清楚地说明发生的情况，但当然有人可能会说你会在您的应用程序中引用统一性。 由你决定。
I agree with Mendelt, there is no "best" DI framework. It just depends on the situation and they all have pros and cons. think David Hayden said on DotNet Rocks that Unity is the preferred choice if you use the rest of EntLib and are familiar with that. I personally use Unity because my customer likes the fact that it says Microsoft Enterprise Library (Unity) on the DLLs, if you get what I´m saying.
I use both both xml configuration for setting up the interfaces and their concrete implementations but then I use attributes in code when injecting, like:
and in code:
Personally I think that makes it clearer what happens, but of course one could argue that you will have references to unity all over your application. It´s up to you.
http://www.palmmedia.de/blog/2011/8/ 30/ioc-container-benchmark-performance-comparison
Unity 更快，但不是最好的
http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison
Unity is faster but it is not the best