Dice is a Dependency Injection Container for PHP. It allows you to very quickly and simply use Dependency Injection techniques in your code with very minimal effort on your end.

The article talks some about the features of the Dice DIC and shares a simple introduction to its use in a more practical example. It uses constructor injection and type hinting to automatically handle the injections based on its current set of object references.

With Dice you don't have to worry about how the User accesses the Session object, you add it as a constructor parameter and it Just works. You don't need to reconfigure the container, you don't need to do anything at all. You just alter the constructor definition and everything is done for you.

You can find more details about Dice in this post (including more examples of it in action and a link to it's repository on github.

The question I have is what if a dependency in one class also has a dependency? To illustrate what I mean, here's an example with some code to follow. [...] I'm not really concerned about the code here as much as I am about the concept that I'm trying to illustrate, in order to use a dependency injection container for this scenario.

In his example code, he shows a "DBAuthMethod" class that extends the "AuthMethod" interface and an "Auth" class that requires an instance of "AuthMethod" as a constructor parameter. He wonders about constructor versus setter injection and thinks that a mix of the two may not be the best structure for the code.

I just can wrap my mind around a scenario where you could ONLY use a DIC, and if you can't use the concept exclusively what benefit is there to using it?

Have any suggestions to share? Let him know - this is a problem more and more developers run into as DIC becomes more widely used.

If we are working within a Symfony2 application or a PHP application that uses the Symfony's Dependency injection container component you can easily integrate this simple script in the service container. I will show you the way that I use to do it.

His sample code uses the Guzzle HTTP library and some configuration options from a YAML file to create a new service hooked into the Twitter API with his credentials. He then imports it via his services configuration and shows an example of it in action - getting the latest contents of his timeline.

To DiC, or not to DiC: that has seemed to be the question in PHP for the last few years. Most people generally agree that injecting dependencies is the right thing to do. For those writing a framework, or any shared codebase where extensibility or the ability to grow the codebase is a core philosophical tenet, not injecting dependencies is doing a disservice to the project in the long run. So, as I've stated before, the question becomes how do we manage the added complexity that comes with practicing dependency injection?

He briefly covers two topics that are often confused - the concepts of a service locator and a true dependency injection container. He then talks about the more correct situations to use each of them, mentioning a few questions you can ask about your app to determine the best fit. To illustrate, he includes a simple example where he mixed the two - DIC for models and service location for the controllers.

Recently I've picked up the Silex framework for a project I'm building. It uses a service container for managing dependencies in your application [Pimple], which is great for defining (not instantiating) objects and their default behaviors in a single location, rather than sprinkled throughout your code in a multitude of places. [...] Using Pimple you can define several hundreds of objects, and then easily instantiate them using the container object.

He goes through some example code showing how to use Pimple to create and manage the dependencies by creating several instances of DateTime objects. He shows how this can then be "upgraded" to a service container by defining something like a PDO object (database connection) inside it. He also mentions some of the benefits that come with its use - easy resource swapping, simpler mocking for testing and allows the use of the Inversion of Control pattern.

Lately I've been playing around with the CloudVPS ObjectStore, which is currently in beta phase. This blogpost shows the options of this ObjectStore in a practical way and concludes with a summary of commands you can use yourself to interact with it and some ideas. For this post, I assume you are familiar with cURL, REST and HTTP headers.

He shows how to make the requests for:

• Authentication
• Working with containers
• Adding files to a container
• Setting access permissions

I am a firm believer that service containers are not a form of Dependency Injection, and are only slightly better than global variables. That led me to make a few comments that elicited a reply from two Fuel developers. That led to a rather interesting debate that just couldn't fit into 140 characters [on Twitter]... So I'm going to go into topics that are tightly related: variable scoping and service locators.

He starts by defining what global variables are (including the requisite Wikipedia definition) and how they're commonly use "everywhere" in the application, both set and read from. He contrasts this idea against a static variable from a class and redefines the scoping a bit when talking about objects and their properties.

So how does this apply to service locators (aka service containers or dependency injection containers)? Well, all state that's managed by a service locator immediately becomes global state to the objects that use the locator. So why is it all the rage? It's simple. It seems simple on the surface. If your object needs another dependency, there's no need to adjust how it's constructed, just pull it from the locator. Sounds great, right? Well, not quite.

He points out some of the main issues with using service locators namely difficulty in unit testing them, dependencies within the container, how it violates both the Law of Demeter and the Single Responsibility Principle as well as causing "hidden coupling" issues.

Last week, I blogged about looking for a new application framework to use and more importantly the key things that I would want in one. After reading about the Zend framework, Symfony and Laravel and finding myself hesitant to use any one, I thought to myself why not get the best of each framework? So that's what I did.

He shows a bit of the code to get them to all play nicely together using the Zend autoloader to register the other namespaces and creating a Symfony DI container inside of the ZF Bootstrap and providing it as a resource. You can find more of the source involved in the integration on his github account.

Doctrine's DataFixtures are a great way to add test data to your application. It's fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn't a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

If you have worked with frameworks such as Spring or Google Guice, you will understand the power and flexibility that dependency injection provides your humongous code base. [...] One quick drawback that I see is that the stateless nature of PHP makes things like object containers not very practical.

He proposes a slightly different kind of dependency injection system, one more akin to what's provided in the Java world where annotation and reflection are components of the integration. He provides a code sample of how this would look and points to Java's JSR-330 standard for some of the annotation examples (like "@inject" or "@scope").