Ninject vs Unity for DI [closed]

Question

We are using ASP.net MVC.

Which of these is the best DI framework Ninject or Unity and why?

Bryant

NInject is better because you can buy cool branded magnets from their website. – Chaechaeronea

Updated version of this question (very similar anyway) that some people may find useful: #4582291 – Ophidian

Answer 1

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.

Amok

You only need to use the Inject attribute if there is more than one constructor and you need to tell Ninject which constructor to use. By default it uses the constructor with the most number of parameters. – Sholom

In the meantime, there is also an official Ninject.Web.Mvc extension. You change your MvcApplication to derive from NinjectHttpApplication, spin up the Kernel in it and call RegisterAllControllersIn(Assembly.GetExecutingAssembly()) to have it take care of all controllers in the given assembly. Magic. – Suspension

This answer is now pretty irrelevant with reagrd to Ninject 2. Whilst the complaint was legitimate for Ninject 1, Ninject 2 allows one to work without littering there classes with attributes. ninject2 will operate transparently without the need to modify your classes. – Hurlee

Same for unity as it appears to be completely configurable via code at this point (v3.0.1304.1) – Clef

Answer 2

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.

Frenchpolish

Answer 3

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.

Cresol

Answer 4

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:

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

and in code:

[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.

Chickie

Answer 5

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

Unity is faster but it is not the best

Ihram