Question about Pimple and making the DI container accessible

I am familiar with the concept of dependency injection, and found a class called Pimple at As per the documentation, I can use the container without problems, but I’m wondering if making the container values accessible through a static class is considered bad.

$container = new Pimple();

$container['x'] = 'foo';
$container['y'] = 'bar';

class Container { public static $values = array(); }
Container::$values = $container;

This makes it easy to use the container anywhere because I can call Container::$values to grab the entire container, or Container::$values[‘x’] to grab foo. So, is this type of usage bad? I’ve just started in with unit testing, so I’m not sure if this is bad for that or not. Anything else to consider?

Pimple when used like this would end up being a pure service locator.

The difference between the two is discussed here

The main point is at what depth of your application does it become context(scenario) agnostic (i.e. it doesn’t care what page it is one or what the components are actually doing a deeper level of operation). Whenever something asks for something versus it is given something it becomes a knowledge owner of the context because it it has to specifically know what to ask for and what the end product will likely be. This in turn hinders polymorphism as that level cannot/has no point in becoming an abstract interface (what is the point of adhering to Liskov which is about substitution when the common pattern is to to require and not to substitute?). With injection(being given) you can refactor out functionality and reinject as a strategy e.t.c. keeping the context aware actual concrete implementation decision as high as possible which in turn keeps things more malleable. Though you could try polymorphism injecting sibling pimple constructions but thinking of trying to maintain that is hurting my head right now.

From a testing point of view there is much less difference, with mocking you are always testing to an interface contract because that is what is really being faked. They both allow implementation replacement without things like autoloader trickery/partial mocking of the tested classes creation methods e.t.c.

This sidelines into trying to make things context agnostic with setter injection after something has been requested but that opens up the objects interface to allow its running implementation to be mutable through any call chain it may be further passed through.

This stuff sounds all a bit computer sciencey but its about what helps to be able to keep a clear high level viewpoint to base architectural design decisions off. If the view point is not clear that hinders further good design as you have to rely on on the spot opportunistic decisions more and more leaving the design more and more to chance.

Thanks for the reply. I’ve read your post 3 times and have taken a look at the link you provided. I’ve been working on my own private PHP framework, and I like the way it works, but there are some decisions to be made regarding dependency injection and whether or not this service locator would be worth implementing in some parts of the framework.

I’ve been using PHP nearly full time for 7 years, am self taught, and perhaps a bit stubborn when it comes to doing what other people say is the right thing to do. I’ve worked with Kohana a bit, spent a little time with Laravel, and spent about 4 years working with CodeIgniter (which many people obviously hate). On one hand there is a programming community’s viewpoint of what’s right, wrong, acceptable, etc, and then on the other hand is that my framework is so simple that its awesome. There is really no part of it that would be hard to understand when browsing the code. The whole framework has been about what I like, and what works best for me. Sometimes I just need to know what that is, hence my question.

I was watching a video yesterday about dependency injection using Pimple, and so I replaced my homemade IoC class with Pimple. The video referenced “service oriented architecture”, and it seems that the Container actually becomes a dependency. I’m very happy with the fact that no objects are created until I need them, which seems better than directly injecting an object because if I don’t actually use the object then I created it for nothing. Does that make sense? In that respect it seems like dependency injection could actually be a waste of resources.

As it stands I have a completed beta version of my framework, and so now the time to consider if any big changes need to be made.

Have you looked at silex:

In Silex, the main app class actually extends the Pimple container. Which means that all the high level bootstrap stuff which done in the app class has access to the container.

Symfony 2 has an interesting “feature”. They defined a ContainerAwareInterface with a setContainer method. Any class which implements ContainerAware automatically gets injected with the container. Makes it a bit easier to pass the container around.

I found this tutorial to be useful:

As far as your original question goes, my own instinct is to avoid globals and static singletons. But that is just me. Hard to offer an useful opinion without seeing the rest of your classes.

I would say that you do want to minimize the number of classes that actually need access to the container. But that is often much easier to say than to do.

The Silex Application class is very interesting. I like the idea of everything automatically having access to the container.

I’ve already read some of Fabien’s stuff, but I’ll have to read that article later today when I have some time. Thanks for the reply.