L’injection de dépendances

1. Apports dans une architecture applicative

Dans une application traditionnelle, c’est-à-dire sans framework, les différents composants applicatifs sont liés entre eux par le programmeur ; c’est lui qui doit prendre à sa charge dans son code la communication entre les éléments du modèle, de la vue et du contrôleur. Cela implique de fournir une quantité assez conséquente de « code technique » en plus du code fonctionnel, nuisant à la productivité des développeurs.

Les frameworks de développement actuels apportent tous plus ou moins un conteneur logiciel qui va se charger de l’inversion de contrôle. Il faut voir l’inversion de contrôle comme un mécanisme où le flot d’exécution est déjà tout tracé (bien que configurable) et où les composants...

1. Principes de base

L’idée qui sous-tend l’injection de dépendances est simple : au lieu de laisser une classe aller chercher elle-même les dépendances dont elle a besoin, ce processus est externalisé.

La classe X, allégée de cette tâche, pourra se concentrer sur sa fonction première. 

Découvrons ci-après les différents types d’injection.

2. Les différentes techniques d’injection de dépendances

<?php 
 
class X 
{ 
    private $db; 
 
    public function __construct(\PDO $db) 
    { 
          $this->db = $db; 
    } 
 
    public function foo() 
    { 
        $stmt = $this->db->query('SELECT...'); 
 
        // ... 
    } 
 
    // ... 
} 

1. Les services

Un service est un objet PHP prêt à être utilisé et ayant une tâche générique et unique. Il peut servir à « persister » des données en base, envoyer des e-mails ou écrire des logs.

Un service est accessible au travers du Service Container et le framework Symfony possède par défaut un certain nombre de services.

2. Explications au travers d’un service X

Penchons-nous maintenant sur la création d’un service X donné, basé sur notre classe X (cf. au début de ce chapitre pour la définition de la classe).

Tous les services étant définis dans le Service Container et accessibles uniquement au travers de celui-ci, la création de ce service sera faite dans la classe représentant le...

1. Créer un service

Le moyen le plus simple de créer un service est de le configuer via le fichier config/services.yaml. Les services doivent être définis sous la clé services :

# config/services.yaml 
 
services: 
    my_pdo: 
        class: PDO 
        arguments: ['mysql:host=localhost', 'bilal', 'pass'] 

Cette configuration crée un service my_pdo, qui est une instance de PDO (clé class). Les arguments passés au constructeur sont définis sous la clé arguments. Concrètement, avec cette configuration, le service my_pdo est créé de cette manière :

<?php 
 
$service = new PDO('mysql:host=localhost', 'bilal', 'pass'); 

2. Les différents types d’injections dans un service Symfony

# config/services.yaml 
 
services: 
    my_pdo: 
         class: PDO 
         arguments: ['mysql:host=localhost', 'bilal', 'pass'] 
    x: 
         class: X 
         arguments: @my_pdo 

<?php 
 
$myPDO = $serviceContainer->get('my_pdo'); 
 
$service = new X($myPDO); 

1. La configuration

Le principe est assez simple : toutes les classes que vous créez (à quelques exceptions près) sont enregistrées en tant que service, et donc injectables les unes dans les autres. Vous pouvez aussi injecter des services Symfony dans celles-ci. Ce comportement est rendu possible par la configuration par défaut fournie dans le fichier config/services.yaml, dont voici le contenu avec ladite configuration mise en gras :

services: 
   # default configuration for services in *this* file 
    defaults: 
      autowire: true      # Automatically injects dependencies in 
                          # your services. 
      autoconfigure: true # Automatically registers your services as 
                          # commands, event subscribers...

1. Le concept de bundle

Dans les versions précédentes du framework (avant Symfony 4 pour être exact), tout le code d’une application devait être organisé dans des bundles. L’objectif de cette approche consistait à faciliter la réutilisation et la distribution de fonctionnalités. Bien que ce système d’organisation ne soit plus obligatoire, il n’en reste pas moins toujours utilisable si vous souhaitez développer des fonctionnalités et les redistribuer.

// src/MonEntreprise/AdminBundle/MonEntrepriseAdminBundle.php 
namespace App\MonEntreprise\AdminBundle; 
 
use Symfony\Component\HttpKernel\Bundle\Bundle; 
 
class MonEntrepriseAdminBundle extends Bundle 
{ 
 
} 

return [ 
   // ... 
   App\MonEntreprise\AdminBundle\MonEntrepriseAdminBundle::class 
       => ['all' => true], 
];