Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

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.

As more frameworks and libraries, particularly in the PHP world, move towards adopting the Dependency Injection pattern they are all faced with the problem of bootstrapping their application and constructing the object graph. In many cases this is solved by a Dependency Injection Container (DIC). Such a container manages the creation of all the things. The things it manages are services. Or are they?

He notes that, according to some of the principles of domain-driven design, "services" should be stateless - the results of calls to the service shouldn't alter it, it should only depend on the values passed in. He goes on to put this into the context of a DIC and gives an example of the "request service" (and how it violates the DDD principles of statelessness). He talks some about scopes (dependencies) and mutable services. He talks about methods to get around these issues with the "request" instance, ultimately coming to the conclusion that event listeners might be the way to go.

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.

In application development, we try to create independent modules so that we can reuse code in future projects. But, it's difficult to create completely independent modules which provide useful functionality; their dependencies can cause maintenance nightmares unless they are managed properly. This is where Dependency Injection comes in handy, as it gives us the ability to inject the dependencies our code needs to function properly without hard coding them into the modules.

They start with a look at the problem with working with "concerete dependencies", ones that are hard-coded into your classes making them not only hard to test but potentially difficult to maintain. They include an example of this (a "SocialFeeds" class and friends) and then one of two ways to fix the situation. They start with using constructor-based injection, injecting the Twitter service into the main feeds object. They also talk about another method - setter-based injection - where the objects are injected via specific methods on the object.

As a third alternative, though, they get to using Pimple to manage the objects, making it easier to inject just the one resource into your classes and extract the objects you need from there. There's also a bit of "advanced" usage of Pimple showing the use of the "share" and "extend" methods.

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.

This week, we're going to talk about the topic of Dependency Injection in Object oriented code (specifically PHP). You don't need a fancy container to do it, it's actually quite simple to do manually!

He also talks some about the difference between a dependency injection container and a service locator. This is just the latest in his video series - he has others covering things like prepared statements, encryption and references in PHP.

As Zend Framework 2 is well and truly here, before some of us who are new to it dive right on in, whether you're completely new or, like me, migrating from Zend Framework 1, it's really important to ensure that we understand the core concepts on which it's based. [...] In this, the first part in the series, I'm going to go through what dependency injection (DI) is. However, as there are a number of great posts already available on the topic by some very experienced developers, [...] I'm not going to rehash them.

Instead he extracts out useful tips from posts of a few other sources on ZF2 and dependency injection in general: Matthew Weier O'Phinny, the ZF2 manual, Martin Fowler on dependency injection, Wikipedia and more. He also includes lots of links to more great articles on the subject, both ZF2-specific and for DI iin general.

Dependency injection has been a frequent subject of discussion among many corporate developers in the past few years. Many feared that they might sacrifice too much time building their application architecture without doing any real work. In this article, I'll explain why PHP developers should consider taking advantage of dependency injection, when building large, scalable projects.

They start off with the "what" if dependency injection, showing the refactoring of two classes using the "controller injection" method of dependency management. There's also some mention of its ability to help clean up a code base, some of the DI tools that are out there (like Pimple) and some good cases of when to use DI in your app.

Recently, I gave a lunch-and-learn to my team on the topic of Dependency Injection (DI). Instead of showing a bunch of slides explaining what DI is and what it's good for, I created a small project and demonstrated the process of migrating a codebase that does not use DI to one that does. Each stage of the project is a different tag in the repository. The code can be found on Github: http://github.com/jadell/laldi. Checkout the code, and run composer install. To see the code at each step in the process, run the git checkout command in the header of each section.

He goes through each "checkout" step (the title is the git command to run to follow along) showing how he migrated away from a simple micro-framework based site to one that defines the various objects (and repositories) inside the "application" object. He adds in a few comments to let you know a bit more about what's going on and some basic event handling. He finishes off the post with some potential issues that could come up both during the process and with the resulting application.