Autofac or Ninject? - which should I go for?

Question

I'm hitting paralysis by analysis I think...

Which should I go for for my first IOC container: Autofac or Ninject?

(Just want an open source, nice and simple, IOC container)

Answer 1

Just want an open source, nice and simple, IOC container

Then Ninject should be your choice, it is very, very, VERY simple and nice. Also it has a very funny documentation =)

Answer 2

I use Ninject. With Ninject2 the syntax is even more concise and easier to use. There are integrations with a ton of other projects inherently (like Common Service Locator) or externally through the Ninject.Extensions series of projects by Ian Davis.

Autofac looks very cool and is apparently fast but the syntax is fairly complicated and there is a steeper learning curve.

Answer 3

Autofac 2!

Autofac 2 will enforce better design by not (by default) performing automatic self-binding for concrete types.

Autofac 2 has auto-generated factories (if a registration is added for IAmAnInterface, you can request Func<IAmAnInterface> to get a factory object, without ever explicitly registering Func<IAmAnInterface>.

With its awesome registration syntax, you can harness the power of Ninject Providers with inline code written right into your configuration classes/modules.

Autofac 2 actually supports more higher-order dependencies than just Func<>. Check out The Relationship Zoo for more automatically resolved types you can request.

The learning curve of Autofac 2 is a little higher (I'm still pretty new), but if you already understand proper dependency injection (and aren't planning on using a container just for service location), then it is worth learning. You can create your own convention-based resolution rules with Autofac in very few lines of code. For example, the following 7 lines of code set up all my presenters and command executors:

        builder.RegisterAssemblyTypes(typeof(IPresenter).Assembly)
               .Where(t => t.IsAssignableTo<IPresenter>())
               .OnActivating(e => ((IPresenter)e.Instance).SetupView());

        builder.RegisterAssemblyTypes(typeof(IExecutor<>).Assembly)
               .Where(t => t.Closes(typeof(IExecutor<>)))
               .AsClosedTypesOf(typeof(IExecutor<>));

Admittedly, IsAssignableTo and Closes are extension methods, but still, you get the idea.

I haven't used Ninject 2 since it was in beta, so it may have more features that compete well with Autofac's power; nevertheless, my recommendation stays the same. Automatic resolution of higher-order dependencies is really, really radtastic-optimus-prime-atron.

Answer 4

I suppose I'm biased, but I would go with Ninject. How can you not love any library that has a name and all of its documentation based around ninjas?

It's somewhat of a style issue, but to me, AutoFac has always felt "backward" with this syntax:

builder.RegisterType<Foo>().As<IFoo>();

In other words, first you specify the concrete implementation and then bind it to the interface you want to support. The question you usually want answered, though, is for a given interface, which concrete type is the implementation? AutoFac's syntax makes it a little more difficult to visually scan the list and answer this question than Ninject, which goes like:

Bind<IFoo>().To<Foo>();

It's a little bit shorter, and it puts the abstract type first, which means you can easily look at a module and answer the question which concrete type is bound to the abstract type IFoo?

But again, a lot of it factors into personal preference. They're both good, solid libraries that will do pretty much everything you need them to do.

Supported platforms also factor into the decision: Ninject 2.0 runs on Mono and .NET Compact, which Autofac doesn't claim to support. On the other hand, Ninject needs version 3.5 of the .NET Framework to run, whereas Autofac can still run on the 2.0 Framework. So it's possible that your particular environment might force your hand; otherwise, try both and see which one works better for you. They're both very easy to get up and running.