Shameer C has a post to his site showing you how to automatically inject values in constructors on Slim 3 based applications. This makes use of the inheritance of constructor parameter functionality the Aura.DI container makes available.

In the previous blog post we have discussed how to replace the default Pimple Container with Aura.DI in Slim framework 3. Aura.DI gives us more flexibility in terms of managing dependencies. We saw one most useful feature in Aura.DI, Inheritance of constructor parameters, that will help us to avoid repeating common parameters for Controllers and Models. In this article we will see another advantage of the same feature.

He gives an example of how, with the default DI container in Slim (Pimple) you have to make a new instance of a class manually each time you need it. He talks about how Slim 3 internally resolves controller classes (using a CallableResolver) and a small change that can be made to prevent you from needed to define every constructor into the DI container and allow for more dynamic handling.

In a post to his site today Shameer C shows you how to replace Pimple in Slim 3 as an application's dependency injection container. He replaces it with the Aura.Di container, a relatively easy replacement thanks to the container interoperability efforts.

Slim framework is my go-to micro framework for all small projects because of it's simplicity and easiness to use. The new version of this cool framework is just around the corner and they have released RC-1 a few days back. [...] Slim 3 has a default DI Container that extends Pimple. [...] Though Slim uses Pimple by default, we can replace it with any DI container that implements Container Interoperability interface, which is a really great feature. The only caveat is Slim sets some of it's required services from the default container. So we should do it by ourself when we use a different library.

He starts by talking a bit about the Aura.Di container and how it's different than what Pimple has to offer. He then links to a small library that makes the bridge between Slim 3 and Aura.Di and sets up the services Slim needs to operate correctly. He then steps through the code needed to integrate this into a simple Slim application based on this skeleton. Most of the work is done in the dependencies.php file where Slim's needs are set up, configured and injected into the container.

Paul Jones has a new post to his site today with his thoughts about where dependency injection belongs in the application layer structure.

James fuller asks: "any thoughts about which layer of the application we should be using a DI container like Aura.Di? Highest layer possible?" Twitter is too constrained and ephemeral for a good response, so I’ll answer that question here.

Based around his definition of a dependency injection container (and service locator), he suggests that the DI container should reside outside of the normal application structure, possibly created in the bootstrap. He also talks some about class inheritance and the use of dependencies passed through from parent to child classes (and how common practices can break this).