Analyse de l'injection de dépendance PHP et de l'inversion de contrôle

Cet article présente principalement les informations pertinentes sur l'injection de dépendance PHP (DI) et l'inversion de contrôle (IoC), qui ont une certaine valeur de référence. Les amis intéressés peuvent s'y référer

Première injection de dépendance Il parle de la. C'est la même chose que l'inversion de contrôle. C'est un modèle de conception. Ce modèle de conception est utilisé pour réduire le couplage entre les programmes. Je l'ai étudié pendant un moment et j'ai vu qu'il n'y avait pas d'article correspondant sur le site officiel de TP, j'ai donc écrit cette introduction. Jetons un coup d'œil à ce modèle de conception, dans l'espoir d'apporter un peu de force à la communauté TP.

Tout d'abord, ne cherchez pas à définir ce modèle de conception, sinon vous serez certainement confus. L'auteur en est profondément affecté. Il existe de nombreux articles sur Baidu, qui sont tous décrits à partir d'un. point de vue théorique. Il y a beaucoup de vocabulaire inconnu, ou il est décrit par du code java, qui est également inconnu.

Quoi qu’il en soit, j’ai enfin un peu de clarté. Décrivons le concept d’injection de dépendances du point de vue de PHP.

Supposons que nous ayons ici une classe qui doit utiliser une connexion à une base de données. Selon la méthode la plus primitive, nous pouvons écrire cette classe comme ceci :

class example {
  
  private $_db;
  function __construct(){
    include "./Lib/Db.php";
    $this->_db = new Db("localhost","root","123456","test");
  }
  function getList(){
    $this->_db->query("......");//这里具体sql语句就省略不写了
  }
 }

Processus :

Incluez d'abord le fichier de classe de base de données dans le constructeur

Puis transmettez-le dans la base de données via new Db Les informations de connexion sont instanciées ; la classe db ;
alors la méthode getList peut appeler la classe de base de données via $this->_db pour implémenter les opérations de base de données.

Il semble que nous ayons atteint la fonction souhaitée, mais c'est le début d'un cauchemar, exemple1, exemple2, exemple3... de plus en plus de classes devront utiliser le composant db. ils sont tous écrits comme ceci. Si oui, si un jour le mot de passe de la base de données est modifié ou si la classe de la base de données change, ne serait-il pas nécessaire de revenir en arrière et de modifier tous les fichiers de classe ?

ok, afin de résoudre ce problème, le modèle factory est apparu. Nous avons créé une méthode Factory et obtenu l'instance du composant db via la méthode Factory::getDb() :

class Factory {
  public static function getDb(){
    include "./Lib/Db.php";
    return new Db("localhost","root","123456","test");
  }
 }

L'exemple de classe devient :

class example {
  
  private $_db;
  function __construct(){
    $this->_db = Factory::getDb();
  }
  function getList(){
    $this->_db->query("......");//这里具体sql语句就省略不写了
  }
 }

Est-ce parfait ? Repensez à toutes les classes à l'avenir, exemple1, exemple2, exemple3..., vous devez obtenir une instance Db via Factory::getDb(); en fait, vous interagissez directement avec la classe Db à partir de l'original. Le couplage devient un couplage avec la classe Factory. La classe factory vous aide simplement à regrouper les informations de connexion à la base de données. Bien que lorsque les informations de la base de données changent, il vous suffit de modifier la méthode Factory::getDb(), mais soudain, un jour, la méthode factory. le nom doit être modifié ou la méthode getDb doit être renommée, que devez-vous faire ? Bien sûr, cette exigence est en fait assez foutue, mais parfois cette situation existe. Une solution est la suivante :

Nous n'instancions pas le composant Db depuis l'intérieur de la classe d'exemple. Nous nous appuyons sur une injection depuis l'extérieur. Qu'est-ce que ça veut dire? Regardez l'exemple suivant :

class example {
  private $_db;
  function getList(){
    $this->_db->query("......");//这里具体sql语句就省略不写了
  }
  //从外部注入db连接
  function setDb($connection){
    $this->_db = $connection;
  }
 }
 //调用
$example = new example();
$example->setDb(Factory::getDb());//注入db连接
$example->getList();

De cette façon, la classe exemple est complètement découplée de la classe externe. Vous pouvez voir qu'il n'y a pas d'usine. dans la méthode de classe Db ou la figure de classe Db. On y injecte directement l'instance de connexion en appelant de l'extérieur la méthode setDb de la classe exemple. De cette façon, l'exemple n'a pas à se soucier de la façon dont la connexion à la base de données est générée.

C'est ce qu'on appelle l'injection de dépendance. L'implémentation ne crée pas de relation de dépendance dans le code, mais la transmet en tant que paramètre. Cela rend notre programme plus facile à maintenir, réduit le couplage du code du programme et obtient un couplage lâche.

Ce n'est pas encore fini. Supposons qu'en plus de db, d'autres classes externes soient utilisées dans la classe exemple. On passe :

<.>

Est-ce qu'on écrit autant de sets sans fin ? Êtes-vous fatigué ?

$example->setDb(Factory::getDb());//注入db连接
$example->setFile(Factory::getFile());//注入文件处理类
$example->setImage(Factory::getImage());//注入Image处理类
 ...

ok, pour ne pas avoir à écrire autant de lignes de code à chaque fois, nous avons eu une autre méthode d'usine :

Instance Lorsque je passe à l'exemple, cela devient :

class Factory {
  public static function getExample(){
    $example = new example();
    $example->setDb(Factory::getDb());//注入db连接
    $example->setFile(Factory::getFile());//注入文件处理类
    $example->setImage(Factory::getImage());//注入Image处理类
    return $expample;
  }
 }

Cela semble parfait, mais pourquoi ai-je l'impression d'être de retour sur scène lorsque je le fais pour la première fois avez-vous utilisé la méthode d'usine ci-dessus ? Ce n’est en effet pas une bonne solution, c’est pourquoi un autre concept est proposé : les conteneurs, également appelés conteneurs IoC et conteneurs DI.

$example=Factory::getExample();
$example->getList();

Nous avons initialement injecté diverses classes via la méthode setXXX. Le code est très long et il existe de nombreuses méthodes. Bien qu'il puisse être empaqueté via une méthode d'usine, ce n'est pas si cool. la méthode setXXX, c'est tout. Il n'y a pas besoin d'empaquetage secondaire avec des méthodes d'usine, alors comment pouvons-nous implémenter l'injection de dépendances ?

Nous introduisons ici une convention : passer un paramètre nommé Di $di dans le constructeur de la classe exemple, comme suit :

Di est le conteneur IoC. Le soi-disant conteneur stocke les instances de diverses classes que nous pouvons utiliser. Nous définissons une instance nommée db via $di->set() car elle est transmise via une fonction de rappel. ne sera pas instancié immédiatement lorsqu'il est défini, mais sera instancié lorsque $di->get('db') est exécuté De même, le mode singleton peut également être intégré dans la conception de la classe di.

class example {
  private $_di;
  function __construct(Di &$di){
    $this->_di = $di;
  }
  //通过di容器获取db实例
  function getList(){
    $this->_di->get('db')->query("......");//这里具体sql语句就省略不写了
  }
 }
$di = new Di();
$di->set("db",function(){
  return new Db("localhost","root","root","test"); 
 });
$example = new example($di);
$example->getList();

De cette façon, il suffit de déclarer une classe Di dans la portée globale, de mettre toutes les classes qui doivent être injectées dans le conteneur, puis de passer le conteneur dans l'exemple en tant que paramètre de le constructeur, puis dans la classe d'exemple, récupérez l'instance à partir du conteneur. Bien sûr, il n'est pas nécessaire qu'il s'agisse d'un constructeur. Vous pouvez également utiliser une méthode setDi(Di $di) pour transmettre le conteneur Di. En bref, l'accord est conclu par vous, il vous suffit donc de le connaître vous-même. .

De cette façon, l'injection de dépendances et les concepts clés de conteneurs ont été introduits, et le reste consiste à l'utiliser et à le comprendre dans la pratique !

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!