have recently been writing a collection of PHP components exploring different design patterns for building applications. With the MVC layer close to completion I decided to write a couple of guides on how these components could be wired together to achieve several different application formats. First in this series will highlight the power of OrnoDi when used to resolve your objects, to do this we will be building a simple RESTful api with the minimal amount of configuration and bootstrap code.

He includes instructions to install the components (via Composer) and configure the DI container with the needed settings. He shows examples of the autoloading setup, how to handle the routing and how to create the sample model and controller to respond to the sample REST requests.

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.

Two months ago I wrote an article about Dependency Injection with PHP and Pimple. After the post I was speaking about it with a group of colleagues and someone threw a question: "What happens if your container grows up? Does Pimple scale well?" The answer is not so easy. Pimple is really simple and good for small projects, but it becomes a little mess when we need to scale.

His solution comes from the Symfony2 framework itself - using its DIC separately from the framework. He includes a configuration example and some simple classes that depend in each other. He also shows how to use imports in the config as well.

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.

While it's fair to admit that factories do have a neat niche in a number of special use cases, I'm not so merciless as to condemn Service Locators and plain Dependency Injection to an unfair exile. In this final part we'll take a closer look at the implementation of these popular patterns so that you can pick up the one that best suits the need at hand.

He talks some about "class collaborators" as used in service locators and using it in his FileStorage example to find and use pre-created objects. He compares this method with a more simple dependency injection approach, noting that not only is it simpler to maintain but also can cause less overhead required for the DIC.

People often ask me what's the one thing they could do for their code base RIGHT NOW that will make it easier to test. To me, the answer is simple: make sure you are using Dependency Injection (yes the link is long and has code samples in Java, but whatever). Without the ability to "inject" your dependencies into your code (whether it is class methods or functions) you will have problems testing modules of code in isolation from each other.

He shows the possible uses of DICs, including code samples, and talks the differences between the two. He explains that the real difference in them is how its being used. When it's used to add and remove instances, it's a container. When its actually put to use and passed into a class, it morphs into a service locator.

After having had a look at Silex, and struggling with the somewhat cumbersome ini configurations and YADIF, I wanted to try out whether I could use Pimple as DI container for ZF 1.x Turns out I can, as you can just select Pimple to be the bootstrap container.

Hsi example (gist of the code here) also shows how to subclass the container and add in some default settings objects into the container. Pimple is a small, lightweight dependency injection container from Fabien Potencier of the Symfony framework.

In this past article I've discussed the dependency injection features when using annotations. This time, we'll see how to use the xml and yaml drivers to do the same (setter and constructor injection). If you don't know how to configure the xml and yaml drivers, please start by reading this.

He describes the different injection methods available with the container - setter injection, constructor injection and method injection. Example configuration content is included - both the XML and YAML versions.

This post will describe a way to integrate Zend Framework 1 and Pimple. A complete working version of the code is available on github. Thankfully, Zend Framework 2 features its own Dependency Injection Container. Happy days. Still, if you're not prepared to wait, you may find this useful.

He shows how to add a resource plugin into the Pimple container - an entity manager that's part of Doctrine. He creates his controller, pulling the manager from the Pimple container and includes a unit test for the controller too (using PHPUnit, but he also suggests Mockery).

So what is Stampie. Stampie is a API wrapper for the most common email sending services. It provides a standard PHP Api to send emails. But mostly it is a project to test TDD and experiment with a couple of different things. Stampie is developed with Dependency Injection and therefore there is a lot of objects. At the start it can be quite cumbersome, but will make a lot of sense if you start to develop and add additional provider.

He includes a bit of sample code showing the sending of a message via the SendGrid API backend. Extending the system is simpler thanks to DI and the customizable MailerInterface object type. There's also an AdapterInterface object that can be used to redefine the HTTP connection interface the tool uses. He also points to the HBStampieBundle bundle for the Symfony2 framework that can make dropping it into your current SF2 application simpler.