Introduction détaillée à l'injection de dépendances et à l'IoC dans Laravel (avec exemples)

Cet article vous apporte une introduction détaillée à l'injection de dépendances et à l'IoC dans Laravel (avec des exemples). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

En tant que développeurs, nous essayons toujours de trouver de nouvelles façons d'écrire du code bien conçu et robuste en utilisant des modèles de conception et en essayant de nouveaux frameworks robustes. Dans cet article, nous explorerons le modèle de conception d'injection de dépendances avec les composants IoC de Laravel et verrons comment il peut améliorer nos conceptions.

Injection de dépendances

Le terme injection de dépendances est un terme proposé par Martin Fowler, qui est l'acte d'injecter des composants dans une application. Comme l'a dit Ward Cunningham :

L'injection de dépendances est un élément clé de l'architecture agile.

Regardons un exemple :

class UserProvider{
    protected $connection;

    public function __construct(){
        $this->connection = new Connection;
    }

    public function retrieveByCredentials( array $credentials ){
        $user = $this->connection
                        ->where( 'email', $credentials['email'])
                        ->where( 'password', $credentials['password'])
                        ->first();

        return $user;
    }
}

Si vous souhaitez tester ou maintenir cette classe, vous devez accéder à l'instance de base de données pour effectuer certaines requêtes. Pour éviter d'avoir à faire cela, vous pouvez découpler cette classe des autres classes, vous avez une des trois options pour injecter la Connection classe sans l'utiliser directement.

Lors de l'injection d'un composant dans une classe, vous pouvez utiliser l'une des trois options suivantes :

Injection de méthode constructeur

class UserProvider{
    protected $connection;

    public function __construct( Connection $con ){
        $this->connection = $con;
    }
    ...

Injection de méthode Setter

De même, nous pouvons également utiliser la méthode Setter pour injecter des dépendances :

class UserProvider{
    protected $connection;
    public function __construct(){
        ...
    }

    public function setConnection( Connection $con ){
        $this->connection = $con;
    }
    ...

Injection d'interface

interface ConnectionInjector{
    public function injectConnection( Connection $con );
}

class UserProvider implements ConnectionInjector{
    protected $connection;

    public function __construct(){
        ...
    }

    public function injectConnection( Connection $con ){
        $this->connection = $con;
    }
}

Lorsqu'une classe implémente notre interface, nous définissons la méthode injectConnection pour résoudre la relation de dépendance.

Avantages

Désormais, lorsque nous testons nos classes, nous pouvons nous moquer des classes dépendantes et les transmettre comme arguments. Chaque classe doit se concentrer sur une tâche spécifique et ne doit pas se soucier de résoudre ses dépendances. De cette façon, vous disposerez d’une application plus ciblée et plus maintenable.

Si vous souhaitez en savoir plus sur DI, Alejandro Gervassio l'a couvert de manière approfondie et experte dans cette série d'articles, alors assurez-vous de les lire. Alors, qu’est-ce que l’IoC ? IoC (Inversion of Control) ne nécessite pas l'utilisation de l'injection de dépendances, mais il peut vous aider à gérer efficacement les dépendances.

Inversion de contrôle

Ioc est un composant simple qui facilite la résolution des dépendances. Vous pouvez décrire l'objet comme un conteneur, et chaque fois qu'une classe est résolue, les dépendances sont automatiquement injectées.

Laravel Ioc

Laravel Ioc est un peu spécial dans la façon dont il résout les dépendances lorsque vous demandez un objet :

Nous utilisons A Un exemple simple l'améliorera dans cet article. La classe
SimpleAuth dépend de FileSessionStorage , donc notre code pourrait ressembler à ceci :

class FileSessionStorage{
  public function __construct(){
    session_start();
  }

  public function get( $key ){
    return $_SESSION[$key];
  }

  public function set( $key, $value ){
    $_SESSION[$key] = $value;
  }
}

class SimpleAuth{
  protected $session;

  public function __construct(){
    $this->session = new FileSessionStorage;
  }
}

//创建一个 SimpleAuth
$auth = new SimpleAuth();

C'est une approche classique, commençons par utiliser l'injection de constructeur.

class SimpleAuth{
  protected $session;

  public function __construct( FileSessionStorage $session ){
    $this->session = $session;
  }
}

Maintenant, nous créons un objet :

$auth = new SimpleAuth( new FileSessionStorage() );

Maintenant, je veux utiliser Laravel Ioc pour gérer tout cela.

Étant donné que la classe Application hérite de la classe Container, vous pouvez accéder au conteneur via la façade App. Le premier paramètre de la méthode

App::bind( 'FileSessionStorage', function(){
    return new FileSessionStorage;
});

bind est l'ID unique à lier au conteneur. Le deuxième paramètre est une fonction de rappel qui est exécutée chaque fois que la classe FileSessionStorage est exécutée. transmettez également une chaîne A représentant le nom de la classe, comme indiqué ci-dessous.

Remarque : Si vous regardez le package Laravel, vous verrez que les liaisons sont parfois regroupées, comme ( view, view.finder…).

En supposant que nous convertissions le stockage de session en stockage Mysql, notre classe devrait ressembler à :

class MysqlSessionStorage{

  public function __construct(){
    //...
  }

  public function get($key){
    // do something
  }

  public function set( $key, $value ){
    // do something
  }
}

Maintenant que nous avons modifié les dépendances, nous devons également changer le constructeur SimpleAuth, et liez le nouvel objet dans le conteneur !

Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau, les deux doivent dépendre d'objets abstraits.
L'abstraction ne devrait pas dépendre des détails, les détails devraient dépendre de l'abstraction.

Robert C. Martin

Notre SimpleAuth classe ne devrait pas se soucier de la façon dont notre stockage est effectué, mais devrait plutôt se concentrer sur la consommation du service.

Par conséquent, nous pouvons implémenter de manière abstraite notre stockage :

interface SessionStorage{
  public function get( $key );
  public function set( $key, $value );
}

De cette façon, nous pouvons implémenter et demander une instance de l'interface SessionStorage :

class FileSessionStorage implements SessionStorage{

  public function __construct(){
    //...
  }

  public function get( $key ){
    //...
  }

  public function set( $key, $value ){
    //...
  }
}

class MysqlSessionStorage implements SessionStorage{

  public function __construct(){
    //...
  }

  public function get( $key ){
    //...
  }

  public function set( $key, $value ){
    //...
  }
}

class SimpleAuth{

  protected $session;

  public function __construct( SessionStorage $session ){
    $this->session = $session;
  }

}

Si nous utilisons App::make('SimpleAuth') pour résoudre la classe SimpleAuth
via le conteneur, le conteneur lancera BindingResolutionException et après avoir essayé de résoudre la classe à partir de la liaison, revenez à la méthode de réflexion et résolvez toutes les dépendances.

Uncaught exception 'Illuminate\Container\BindingResolutionException' with message 'Target [SessionStorage] is not instantiable.'

Le conteneur tente d'instancier l'interface. Nous pouvons faire une liaison spécifique pour cette interface.

App:bind( 'SessionStorage', 'MysqlSessionStorage' );

Désormais, chaque fois que nous essayons de résoudre cette interface à partir du conteneur, nous obtiendrons une instance de MysqlSessionStorage . Si nous souhaitons changer de service de stockage, nous modifions simplement cette liaison.

Remarque : Si vous souhaitez vérifier si une classe a été liée dans le conteneur, vous pouvez utiliser App::bound('ClassName') , ou vous pouvez utiliser App::bindIf('ClassName') pour enregistrer une liaison qui n'a pas encore été enregistrée . Certainement.

Laravel Ioc fournit également App::singleton('ClassName', 'resolver') pour gérer la liaison singleton.
Vous pouvez également utiliser App::instance('ClassName', 'instance') pour créer des liaisons singleton.
lancera ReflectionException si le conteneur ne peut pas résoudre la dépendance, mais nous pouvons utiliser la méthode App::resolvingAny(Closure) pour résoudre n'importe quel type spécifié sous la forme d'une fonction de rappel.

Remarque : Si vous avez enregistré une méthode d'analyse pour un certain type, la méthode resolvingAny sera toujours appelée, mais elle renverra directement la valeur de retour de la méthode bind .

Conseils

Où écrire ces liaisons :

S'il ne s'agit que d'une petite application, vous pouvez l'écrire dans un fichier de démarrage global global/start.php, mais si le projet devient Comme il le devient de plus en plus grande, il devient nécessaire de faire appel à Service Provider.

Tests :

Lorsque vous avez besoin de tests rapides et faciles, pensez à utiliser php artisan tinker Il est très puissant et peut vous aider à améliorer votre processus de test Laravel.

API Reflection :

L'API Reflection de PHP est très puissante Si vous souhaitez approfondir Laravel Ioc, vous devez être familier avec l'API Reflection. Vous pouvez d'abord lire ce tutoriel pour obtenir plus d'informations. [Recommandations associées : Tutoriel vidéo PHP]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!