On the SitePoint PHP blog there's a tutorial posted giving you a "fresh look at dependency injection" using the Disco library from bitExpert.

Dependency Injection is all about code reusability. It’s a design pattern aiming to make high-level code reusable, by separating the object creation / configuration from usage.

[...] Our very own Alejandro Gervasio has explained the DI concept fantastically, and Fabien Potencier also covered it in a series. There’s one drawback to this pattern, though: when the number of dependencies grows, many objects need to be created/configured before being passed into the dependent objects. [...] In this article, we’ll demonstrate the concept [of a dependency injection container] further with a newcomer in this field: Disco.

He starts with the installation of the library via Composer and starting up the built-in PHP web server for testing. With that up and running he shows you how to create an instance of the container and set up a sample service with the configuration in the docblock comments. The tutorial then talks about the service scopes, container parameters and shows it in action to create a simple controller handling frontend. There's a bit more about configuration, the container builder functionality and the creation of a response listener when routes are requested.

On the Toptal.com blog there's a recent post about true dependency injection with Symfony between components in your application and only using the dependency injection container for its intended purpose.

Symfony2, a high performance PHP framework, uses Dependency Injection Container pattern where components provide a dependency injection interface for the DI-container. This allows each component to not care about other dependencies. [...] But this means DI-container can be used as a Service Locator.

[...] In this article we will try to build a Symfony2 application without implementing Service Locator pattern. We will follow one simple rule: only DI-container builder can know about DI-container.

They start off by talking about the structure of the dependency injection container and how it relates to the three main types: controller, method and property injections. He then starts in on creating the sample project and requiring only the Symfony DI, configuration and Yaml components. He then creates a ContainerBuilder class and sets up the HttpKernel functionality to pull the response from the container. He then makes a simple controller with a default action that just responds with text. With this working he updates it to pull in an input variable. He then makes updates to the application with changes to the route handing, templating (Twig), Doctrine (database) and tag handling.

In this new post to his site Alejandro Celaya offers some advice on improving the dependency injection of your application with the help of the Zend Framework plugin managers. More specifically he talks about the AbstractPluginManager, a part of the ZendServiceManager package.

Generally it is a very bad practice to inject a service container into any object, but there are some situations where it could be even good, when certain conditions are met.

In one of the ZF2 mailing lists somebody asked which were these situations. I couldn't find the email, but the answers said that you can do it when the service container manages resources of the same type, and your object virtually depends on all of them. [...] If you have another object that needs to perform database connections, you don't want to inject all of the connection objects into it, you should rather inject the connection pool. That will reduce the number of dependencies of your object.

In this situation, the connection pool is some kind of service container, but injecting it has more benefits than disadvantages.

He shows how to use the AbstractPluginManager to achieve this goal, noting the existence of a validatePlugin method that can be used to ensure all necessary dependencies are available. He includes a real example of it in use, creating a simple "social plugin manager" that verifies that the plugin provided is either a closure or instance of FilterInterface.

If you've heard the term "dependency injection" but are still a little fuzzy on the concept, you should check out this new post to the MyBuilder.com site introducing you to some of the basic concepts and using it in some PHP-based examples. They focus on the use of a dependency injection container in this tutorial (versus something like constructor or setter injection).

A lot has been written about dependency injection or DI (for short) in PHP, but it's a bit difficult to find a tutorial showing how a DI container actually works. The objective of this post is to show the internals and concepts of a DI container.

They start with a brief look at what a dependency injection container is and how it's different from a service locator or regular autoloading. They mention some of the benefits it provides and get into the simple example. They start with a class that creates a hard dependency in the constructor and show how to refactor that out to constructor injection. They then take the next step and replace the constructor injection with a DI container injection and how its internals are set up to provide new instances of requested objects (via a services definition).

The Programming Are Hard site continues its look at structuring Symfony-based applications in part two (it's just two parts) building on the structure and foundation laid out in part one.

It really irks me when I see some design/architecture decisions other developers have made but there's no technical explanation. What packages did they use? What challenges did they face? What trade-offs were made? I'll go over some more specifics in this post.

He recaps some of the things covered in the previous post first, ensuring everyone is on the same page. He then gets into the concept of "bundles" and how they encapsulate functionality. From there he talks about commands, controllers, dependency injection and lots of other topics, each with their own summary and a bit of code where needed for clarification.

The SitePoint Web blog has a recent post with two things that are on the radar when it comes to PHP - the upcoming PHP version and the practice of dependency injection.

To change things up a bit, we’re going to start bringing to you items and information from those discussions that have caught our attention. Sometimes these discussions will be useful and interesting, and sometimes they may be challenging or insightful. Either way, they’re likely to bring new information to light that you haven’t come across before, and will help to provide insight and perspective on topics you’re interested in.

He starts with an overview of the controversy surrounding PHP 7 including its name, feature removal and links to some responses to the proposed changes. The second topic, dependency injection, how it might be evil and some of the opinions that have been expressed around it.

Phil Bennett has returned to a topic he covered earlier to refresh some of the statistics and add a few newer technologies to the mix. In this new post he benchmarks some of the more popular PHP-based dependency injection containers.

A few months ago I wrote a post detailing and benchmarking several dependency injection containers. Recently there have been some changes to some of these containers and some new packages have appeared in the community so I decided to revisit the post and update it a little. When I say a little, I'm going to be re-writing the entire post to give you a little more information about the containers and some more in-depth benchmarks.

Several new DI containers were added including the AuraDi, PHP-DI and LeagueDi. His benchmarks measure the time taken for these operations:

• Extremely nested object fetching
• Registering all objects
• Resolving objects (w/dependencies) using a factory
• Injecting pre-defined constructor values
• Resolving dependencies with setter calls

Code for the test and graphs of the outcomes are provided for each benchmark on the list. There's also a bit of analysis at the end of the post detailing some of the pros and cons of each.

In this new post to his site Jeune Asuncion shows how he integrated several technologies to make for a robust system - Zend Framework (1.11), Doctrine 2 and the Symfony dependency injection system.

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.

In this recent post to Reddit.com there's some commentary about an older article sharing a negative spin on dependency injection and how it could cause more trouble that it's worth.

The attitude of these pattern junkies doesn't work with me. *I* will decide whether or not I will use a particular design pattern, and *I* will decide how I implement it. This usually means that I don't use design patterns at all, and those that I do use are implemented in my own unique way. Because of this I am widely regarded as a maverick, a heretic and an outcast by those who consider themselves to be "proper" OO programmers.

Comments in the Reddit post talk about DI not being a "silver bullet", how it "empowers polymorphism" and how design patterns should not be done for the same of using design patterns

In response to some of the comments made on his previous post about why you should use dependency injection in your applications, Charles Sprayberry is back with some more concrete examples showing how it all works with some code to back it up.

To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.