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.

Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us. [...] To promote compatibility between logging libraries, the PHP-FIG group recently released PRS-3, a common interface for logger objects. In this article, I'll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn't dependent on any particular logging implementation.

He includes a quick introduction to the PSR-3 format, how to get the files you'll need to use it (via Composer). He includes some sample code showing how to make the basic email class with a logger injected for use. Since the Monolog logging project follows the PSR-3 format, it's an easy drop-in option. He also talks about using PSR-3 to avoid having logger dependencies with the "LoggerInterface". There's also a bit at the end of the tutorial showing you how to use the Adapter design pattern to "proxy" the logging calls to the class via a PSR-3 interface.

Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

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.

The DIP deals with avoiding mixing different levels of abstraction in your code. In this article we will explore the last of these principles in depth. [...] I want to show you how depending on abstractions makes our lives easier in a larger example. Since we're going to be loading, updating and storing bikes a lot in our application I would like an Api for that. It would not be such a good idea to write the same queries or perform the same validation over and over.

He includes two examples - one a bit simplistic involving bike storage and another more complex that uses interfaces to define structure and object injection rather than passing data around. He also tries to help clear up some of the confusion that might happen around dependency inversion and dependency injection.