Which single IoC/DI container would you recommend using and why?

Question

I'm asking this question because it's a good way to gauge how the community at large feels about the various containers/frameworks and why. Also, whilst my expertise may lie in .Net development, I am very interested in which frameworks are popular (and why) in other languages. If I feel the need to start digging into Java for instance, then I'd like to hit the ground running with good (comfortable) knowledge that I'm starting in the right direction. Does Ruby even need one with all its magnificent dynamicism? I have my own opinions on the .Net front, and will probably add my own personal favourite in an answer below, but I'm interested in all languages and opinions here.

With all that in mind, could you please state only one IoC/DI framework that you use and recommend with the language of choice (Java/Ruby/.Net/Smalltalk etc.) and your reasoning for your choice, and if someone has already answered your particular flavour, then you can just vote it up and add comments to it so that anyone looking for advice in future and see which frameworks are more than likely to work for them once they read your reasoning. I'm hoping that over time, the best ones will bubble up to the top.

I realise that this question doesn't have only one correct answer, so I won't be choosing one - the community will decide which framework gets the most votes and why. Of course, if you really feel strongly opposed to a particular brand, you could take the reputation hit and vote it down too, and this question can serve as a true wiki-style entry for research into this field.

Remember, only one IoC per answer you write please - if you feel the need to promote two frameworks, then write two answers with your reasoning inside for each choice - then others in the community can agree or disagree with you.

Answer 1

My personal (and recent) favourite is Ninject on the .Net framework for the following reasons:

1. It has been the easiest (to setup) in my experience and most intuitive framework I've used. Hit the ground running in 10 minutes!
2. The documentation is incredible and up to date - very important to me.
3. There is a lot of community support for it (blog posts and screen casts) even though it's one of the younger frameworks.
4. The fluent design is a dream to use and is very discoverable.
5. Configuration is strongly typed - no need for pesky XML config.
6. I have a lot of respect for the author (Nate Kohari) and his contribution to the community seems unwavering.

I hope that helps someone in their decision making process!

Answer 2

In Java, I use the Spring Framework.

This is because:

1. It's popular - you get lots of support. It's a rare day when I come across a problem in Spring which hasn't already been come across and documented on the internet;
2. It's powerful - there are plenty of modules available. For example, Spring Web Services, Spring Web Flow... you just pick what you need.
3. It's easy! - although you do have to write a fair amount of XML, that is being reduced with annotations (new versions of Spring are making much better use of annotations - for example, transaction management can pretty much be handled all with annotations).

There may be 'better' choices for your particular needs but I find Spring works for me!

The Spring website contains some good advice - the reference manual is actually very good and comprehensive. You may also find the Spring Hub useful (requires registration).

Answer 3

Use Guice on Java if you need Dependency Injection. Stay away from Spring as they put way too much of unrelated stuff into their product. Unrelated to dependency injection, that is.

Also, Guice is XML-free (code annotations-only).

And for those who claims that "XML configuration may allow change the application without recompiling"...

• There is no separate "compiling" stage anymore -- just [Ctrl-S] to save the file in any modern IDE and it's compiled already
• Compiler will check Guice configuration and spot most of errors instantly. And XML mistake is to be revealed at runtime... not good.
• And by the way, where should those reconfigured beans code come from?

Answer 4

Castle Windsor

It's amazing to use with Boo based DSL Binsor

Answer 5

While I havn't used it extensively, autofac would be my first choice.

• Configurable from code.
• Zero intrusion (Which means that you can change your mind at any time)
• Flexible lambda-based approach in addition to the traditional reflection based resolving.
• Slimmer than ninject (which would be my second choice).

Answer 6

PS: and there is Boo based DSL configuration syntax for Autofac IoC Container, too ;)

Answer 7

I've personally tried (in the order of switching):

• ObjectBuilder
• StructureMap
• Castle Windsor
• NInject
• Unity
• Autofac

Right now I'm sticking for the last one and using it with the great pleasure in production.

Reasons:

• lightweight core and has great performance - fast enough to create one child container per Http request (if lambda registrations or generated factories are being used)
• Supports proper container nesting and resolution (that's the reason I had to move away from the Castle)
• Has XML, inline code (with efficient C# lambda syntax) or expressive DSL based configuration
• Automatic component scope and lifetime management

But in the long run, you have to pick your own, based on the requirements of your development projects.

Answer 8

The Spring Framework has a well designed IoC container. Spring.NET implements the same concepts for C#/.NET apps. Spring Python carries the same concepts to the python platform.

Spring Java's core container is decoupled from the input format, allowing you multiple choices in wiring your application. They currently have three ways to provide input:

• Classic XML input - This is the most popular style, which has excellent tool support when using the Spring IDE Eclipse plugin.
• Spring JavaConfig - This sub-project allows you to configure using pure java code from a central location. Think: replacing an appContext.xml file with AppContext.java class definition. This easily supports IDE refactoring tools, and has all your information in a centralized location.
• Annotation-based Configuration - This allows annotations to be put in your code where the services and entities are defined, allowing a more decentralized style. This is closest to the way Guice works.

Spring Java also included a concept called "auto-wiring" for each of these mechanisms. Basically, the container deduces what components should be wired together based on static types instead of requiring the developer explicitly specify. Different beans can marked whether or not they are candidates for auto-wiring.

Spring Python's core container provides two ways of wiring your application:

• Classic XML input - Similar to the Spring Java's original format, you can use XML in the format of the legacy PyContainer project.
• Decorator-based - Using Spring Python's @component decorator, you can code up a pure-python code container similar to the Spring JavaConfig project.

Spring.NET provides an XML format

Why pick Spring over another IoC container? Spring has excellent community support, mailing lists, and you have good odds of being able to hire a professional consultant should the need arise. Every module in the framework is optional, so you can pick and choose what you do and don't want to use. Spring also integrates well with other products, including Guice, JPA, EJBs, web services, and other technologies. It makes it easy to tie in with other technologies down the road.

Answer 9

I vote for StructureMap thats because I only tried it, which means it gave me all what I needed and the new version 2.5 has just been released and has promising features.

Answer 10

Be aware of the following limitations of the IOC container. I have to warn people, because I am living with the hell of having to support a system using it:

• Exceptions thrown by constructors get swallowed. You only get the “couldn’t create dependency” exception. That means you can't catch expected exceptions if it's throw in a constructor.
• Can’t step through constructors.
• Forgetting to register an interface breaks at runtime instead of compile time.
• All your classes can only have one constructor and they all have to accept interfaces as parameters.
• All dependencies are instantiated so you can’t share instances, which means your memory usage can get large quickly.
• It promotes a lot of interdepencies which can hide the fact that you code has turned into spaghetti. Making it easier to instatiate all of these interdepencies just masks that there is a potential underlying problem.
• You can't manage your own "Unit of Work" very easily because you can't manage a transaction across multiple dependencies since you didn't have control of instantiating them and passing in the context of that transaction.

Don't get me wrong, I love dependency injection and the inversion of control principle, but I think the IOC container could be used responsibly, but just be aware of the battles that you will need to fight because of the above list.

Answer 11

+1 Castle Windsor

It is mature, huge community support, clear design and quite easy to learn/use as first step.

P.S: Sorry, I cannot vote in Chris Canal's post.