Inversion of Control: Have you ever had to decide what Dependency Injection framework is best for a project? Which one did you pick and why?

Rather than triggering a flamewar on what DI framework is "best" (I don't think there's a definitive general solution), this question is meant to discuss good alternatives for projects of different kinds, no matter the programming language, based on professional experience.

Some issues I'd like to lean about:

• What were the most important features you were looking for in 开发者_运维问答a DI framework? Why was it what best fitted your project?
• What does the DI framework have that others do not? What makes it special?
• Why would you not pick the same DI framework for other different projects?
• How did the DI framework improve the testability and configuration flexibility of the application (especially on different environments: development, staging, production, etc.)?
• Many DI frameworks are said to be simple. But how easy is it to maintain the configuration of dependencies? (For example: Is it too verbose or difficult to read and modify?)

I may eventually accept one answer, but there is no "best answer" on this topic. I would appreciate anyone's experience that is useful to share.

I'm particularly interested in experience with DI frameworks in Python and PHP, where I think the choice isn't very straight-forward. The question is language-agnostic, though.

I usually choose frameworks, whether DI or otherwise, using the following criteria:

1. Pick a framework that has the required functionality for the job at hand
2. Prefer frameworks that are simple - The less "extra" stuff not required for 1., the better.
3. Prefer frameworks "built-in" to the language/framework you're already using.
4. Prefer frameworks that I already know and have used

Usually, by working through the above, it's pretty obvious. For example, the last DI framework I choose was MEF, mainly because it was a C# project (point 3.), it's simple, and it did what I needed it to do.

Well, talking about Java it sounds quite easy... There is Spring with its DI, and if you develop using Spring technology stack, then you just use its DI :) If you use another technology stack, then Spring is not that easy to integrate, and actually do you need it? There is Google Guice :) In comparing to Spring, Guice is all about DI and in this case you will not need to add extra libraries to your class path, maybe some extra configuration etc. And both Spring and Guice implement the same JSR 330 (Dependency Injection for Java)... Well, I think it is pretty easy to decide what to use, Spring or Guice.

On the other hand, there is Java EE 6 coming with its new JSR 299 (Contexts and Dependency Injection for the Java; CDI), which is based on JSR 330. When you are going to use Java EE 6 compliant application server, then it is worth to take a look at CDI, then you won't need extra libraries because application server already understands DI and takes care about it. CDI allows you to make more as it is layered on top of JSR 330 and enhances it.

If you still don't use Spring/Guice then it is good idea to start with CDI

UPDATE: Forgot to mention: CDI is now implemented by Weld project (seamframework.org/Weld), it supports popular servers, so you can try it right now. JBoss AS 6 is shipped with it.

Some comparison between Spring and Guice, as well as advice which one to use: here and here