In a new post to his site David Lundgren wonders when dependency injection becomes an anti-pattern when used in PHP applications. The idea of dependency injection is to provide objects with instances of other objects representing things they'll need to get the job done (goes along with separation of concerns). Unfortunately, if used incorrectly, DICs - dependency injection containers - can become less useful and more of a hinderance than a positive part of the application.

During my tenure as a seasoned, and tenderized, PHP developer I have used many design patterns: adapters, factories, data mappers, facades, etc. The most recent one that I have been working with is Dependency Injection. Inversion of Control is not a new idea, at least not in the programming world, but in the PHP world it seems to have taken us by storm in recent years. Every framework will often have a Dependency Injector built in, or offer it as a component for use. It is the hip thing to do in PHP, but I believe we need to take a step back and evaluate it for what we are really trying to achieve. That is reducing the tight coupling that our objects may have. I view it as removing the new-able’s from our objects code, and handing the object creation over to something else to deal with.

He talks about how dependency injection containers and service locators relate to each other. He also suggests that, at the heart of every dependency injection container, there's a service locator. He gives an example of a project where a large number of dependencies are being injected and how, despite the assumption of flexibility, his dependencies don't change that often, making the DIC and its functionality a bit less important.

Gonzalo Ayuso has a second post in his series looking at using the Symfony2 dependency injection container with Doctrine functionality. In his previous post he talked about sharing PDO connections via the DIC. In this latest one it's focused on the sharing of DBALs from Doctrine.

OK. We can handle PDOs connections inside a Symfony2 application, but what happens if we prefer DBAL. As we know DBAL is built over PDO and adds a set of “extra” features to our database connection. It’s something like PDO with steroids.

He includes the (PHP) configuration to set up the DBAL and the YAML definition to set it up in the DIC's configuration. As an update to the post, he also points out a bundle for Symfony2 that lets Doctrine do this natively - check out this documentation on github.

In his latest post Ralph Schindler takes another look at the usefulness of Dependency Injection Containers and whether or not they're the right thing to use for your situation.

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.

Emanuele Minotto has a recent post with a set of "PHP in a tweet" posts that do all sorts of things.

Yesterday an ex colleague tweeted something that captured my attention, so I started thinking to a Twitter-powered code golfing competition. Looking for other examples.

Tweets included in the list are snippets like:

• A dependency injection container
• A super simple web framework
• A microframework
• Bypassing array_intersect

There's some game rules included in the post so you can contribute your own to the the comments. Several have already been added including a base64 encoding variant and getting the extension of a file.

On NetTuts.com today there's a new tutorial introducing dependency injection and how it compares to other injection types (like setter and constructor). It shows how to apply the "Inversion of Control" methodology to create a container that can be reused across the entire application.

Chances are, at some point in your learning, you’ve come across the term, “dependency injection.” If you’re still relatively early in your learning, you likely formed a confused expression and skipped over that part. Still, this is an important aspect of writing maintainable (and testable) code. In this article, I’ll explain it in as simple a way as I’m capable of.

He starts with an example of setter/constructor injection and talks about how they can make it difficult to use the class as things get more complex. His solution is to create a simple DIC (dependency injection container) that stores instances of objects or closures that can be extracted an reused.

Gonzalo Ayuso has a new post talking about dependency injection today and proposes his own DIC solution (dependency injection container) "when Pimple is not enough".

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.

In his most recent post Anthony Ferrara talks about service containers, the cousin of dependency injection containers (DIC) that he argues aren't much better than global variables.

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.

Kevin Schroeder has a quick new post about using dependency injection in Zend Framework 2 applications using multiple object instances.

When you work with the ZF2 Dependency Injection Container (DiC) when you make multiple requests for an instance of an object you will get the same object back each time. [...] But what if you want the injection benefits of the DiC but don’t want to share the object? Use the DiC’s newInstance method instead with the third parameter being false.

He includes code examples of requesting the object both ways - the usual way that returns the same object and the alternative that passes in a "false" value, complete with a debug output of each object proving they're different.

In this new post to his blog today Marcelo Gornstein looks at doing some dependency injection in a simple application via XML and YAML configurations and the Ding dependency injection container.

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.

Padraic Brady is back today with the second part of his "Dependency Injection in Zend Framework 2.0" series. In this second post he talks about what dependency injection containers are (and aren't) and how they could lead to bad practices if they're considered as service locators.

For Part 2, we’re going to dig more into what a DIC is and isn’t. I’ve already noted one very simple DIC called Pimple which will continue as one of my reference points since it best illustrates just how simple a DIC can be. In Part 3, we’ll (finally) turn our attention to some actual source code. Baby steps. Parts 1 and 2 should get you thinking so that ZF 2.0′s DIC is a lot easier to understand and critique. We don’t want anyone panicking just by throwing them into the deep end.

He talks more about the Pimple DIC tool and how, despite it's similarity to a set of Factory pattern calls, it's slightly different - think of it as "a container of executable Factories". He introduces the concept of a Service Locator, an object that can find and load other objects in an intelligent way. He notes that the most ideal DIC is an "external agent" that defines the object relationships outside of the application.

He points out a feature of ZF2 that allows for injection of the DIC into a controller, allowing it to look up the resources it needs. This of course, has issues - three that he mentions specifically:

• Firstly, this isn’t Dependency Injection.
• Secondly, it creates objects which are useless without the specific DIC interface it depends on.
• Thirdly, DICs are really bad Service Locators.