Currently we rely on PHP-DI as the dependency injection container, but it isn't as well known as Symfony DI nor as easy to use as a developer. The concept of dependency injection is barely used in our code base, although recent push for the technology had its effect, teams (at least in the EU) started to adapt it more and more. It isn't too late to evaluate and replace PHP-DI with a potentially better DI container before we develop such dependencies on PHP-DI which would render moving to an other solution unaffordable.

What it does

Symfony DI gives many methods to configure the container, one of them is using YAML config files. These files are parsed, then dumped into a PHP file which will contain a class, the container it self. This file has to be included into the project. This generated class is one of the main advantages over PHP-DI as the system does not have to spend time on figuring out the dependencies on each page load (I believe PHP-DI is doing that currently)

The YAML config file also gives constraints on how the config should look like, no custom made config loaders based on team preferences: Product Catalog's config, Transportation's config, Extranet

No workarounds like this.

Symfony DI pros:

  • has a very good documentation and large community, for beginners, it is much easier to find examples and answers
  • makes the services private by default, teams can choose what services are visible for the whole application and what services should be used internally
  • since the container is dumped to a PHP class, it is pretty fast
  • many other things like abstract service definitions, support for lazy loading

Symfony DI cons:

  • deploy job has to make sure that the container dump is created before copying files to the production server
  • the container dump has to be updated during development, either manually or automatically
  • we would have to spend a few hours on converting existing config files to symfony format, but this could be done gradually

How we built it

Added the composer packages to the PHP repo and made a few changes so the application will try to fetch the service from Symfony DI and fall back on PHP-DI when the service could not be fetched. We converted some of the existing PHP-DI configs to Symfony's YAML format as an example.

Challenges we ran into

Since the container is dumped to a PHP file after parsing the YAML files, we have to automatically refresh this during development, otherwise changes done to the YAML configs won't be visible for the the system until the dumped container is refreshed manually. To solve this we could set up gulp (or even PHPStorm) to watch changes in the YAML files and run a few liner job which would refresh the container.

Accomplishments that we're proud of

It seems to be doable, but over all it is no rocket science.

What we learned

We've seen that most of the teams took different approaches to set up the container, thus reinventing the wheel.

What's next for Fade out PHP-DI in favour of Symfony DI

We hope that proving that converting configs is not taking much time and showing that the YAML config is more readable than the current config files due to the formatting and language constraints, we can start a conversation about making Symfony DI as the official dependency injection library.

Built With

  • symfony-di-component
  • php7
Share this project: