Approaches to Dependency Inversion: DIC vs passing through constructor parameters

Question

In previous applications I've worked on, I've had a single factory class which built my object structure, and all dependencies were passed to each class through its constructor parameters.

I'm now considering using a DIC framework such as Pimple, in which case it seems like you have a global dependency container which would be referenced inside a class' constructor to instantiate its dependency fields.

Am I missing any other viable approaches to doing dependency inversion? What are the pros and cons to each approach? When would you want to use one approach above another?

Answer 1

Pimple documentation shows how to use it to inject dependencies into your objects constructors, which is definitely the way to use it.

Yes, you have a global dependency container, and no, you don't call it inside a class' constructor.

It replaces your factory class, you ask it to create some top-level object, and it takes care of creating all dependencies recursively according to the rules you gave it.

Answer 2

It seems to me that Pimple is pretty strictly inferior. You have a much tighter coupling to the DI container, and a bunch of hardcoded string keys everywhere that cannot be changed. The constructor parameter approach is much superior because this has zero coupling to the container. For instance, imagine how much fun it would be to write a test using a class with a Pimple container compared to the constructor-arguments approach.