There are plenty of good Dependency Injection Container implementations out there. The selection of an IoC container is not only defined by the developer's preference, which can swing the vote big time since most developers swear by their favorite container, but also of other factors like standards in the organization, the usage of another product which already supports, or favors, a given IoC implementation, etc.

The usage of an IoC container should always be abstracted, making the process of switching between implementations fairly simple, or at least, the refactoring needed to accomplish this task will be minimal compared to the one needed if you were using references to a specific container all over your codebase.

This post from Uncle Bob generated lots of talking on the developer community regarding Inversion of Control (IoC) and Dependency Injection (DI), which is always good for the sake of  learning and general awarness. Almost every developer with a blog posted about their take on this subject. Two people which I respect a great deal and suscribe to their blogs also posted their reactions, please read Ayende and Davy's blogs for a better understanding of their positions.

What I get from all this, in short, is that Uncle Bob accepts the advantages of using dependency injection but prefers to encapsulate the access to the IoC container on factories. Davy seems to accept this approach on another post...