Quels sont les avantages de l'inversion de contrôle dans Laravel

Dans Laravel, l'avantage de l'inversion de contrôle est qu'elle peut utiliser le conteneur IOC pour découpler des modules ou des objets dépendants. Si le service spécifié n'est pas adapté à l'utilisation, l'interface spécifiée peut être utilisée sans modifier les méthodes définies par le développeur. Trouvez un service approprié pour le remplacer.

L'environnement d'exploitation de cet article : système Windows 10, Laravel version 6, ordinateur Dell G3.

Quels sont les avantages de Laravel Inversion of Control

Laravel lui-même est un conteneur IOC, également appelé conteneur de service

Le conteneur de service est un outil pour gérer les dépendances de classe et effectuer l'injection de dépendances

Le rôle de l'inversion de contrôle. consiste à implémenter le découplage de modules ou d'objets, en utilisant un tiers pour découpler les modules ou objets dépendants, et ce tiers est le conteneur IOC.

Les conteneurs y stockent les services requis pour que les développeurs puissent les appeler facilement. Par conséquent, afin de faciliter la gestion de ces services (implémenter le découplage), Laravel a décidé de ne pas appeler ces services directement. Par exemple, le développeur a défini une méthode 1, qui était à l'origine liée au service B et implémentée via le service B. n'est plus B, mais une interface A est définie et le service B est implémenté via l'interface A.

Dans ce processus, le service B aurait pu contrôler une certaine fonction du développeur. Désormais, le développeur n'appelle pas ce service directement, mais utilise à la place l'interface A. Par conséquent, le service B a perdu le contrôle de cette fonction et l'interface A gagne. contrôle de cette fonction. Ce processus est appelé Inversion de Contrôle

L'avantage est  :

Si le service B ne convient pas, alors l'interface A peut trouver un autre service adapté aux besoins. Pour le remplacer, vous ne le faites pas. Je n'ai pas besoin de modifier la méthode du développeur 1. Quant au service que vous utilisez pour l'interface A, je n'ai pas à m'inquiéter de cette méthode. Si cette interface A veut implémenter le service B, alors la classe qui implémente le service B doit hériter de cette interface A, et implémenter la méthode abstraite définie par l'interface A dans cette classe B.

Cette interface A peut également être considérée comme le fournisseur de ce service. Il existe plusieurs fournisseurs de services dans Laravel, et ils forment des composants correspondants. Plusieurs composants forment un tel framework Laravel

Maintenant qu'il existe l'interface A et qu'il y a tant d'interfaces BCDE, afin de faciliter la gestion, le format du fournisseur de services doit être précisé. Paramètres de la méthode, pour contraindre leurs règles, ce concept est appelé : contrat

L'avantage du contrat est que tant que les règles de contrainte sont respectées, il peut être remplacé selon les besoins,

**Façades, ** On peut l'appeler façade, en fait il s'agit d'un ensemble d'interfaces statiques ou de proxys qui permettent aux développeurs d'accéder facilement à divers services liés au conteneur. Laravel est livré avec certaines façades, telles que le cache, etc. Une Facade est une classe qui peut être utilisée pour accéder à un objet depuis le conteneur. Cette fonction est définie dans la classe Facade. Les façades de Laravel et toutes les façades que vous définissez vous-même hériteront de la classe Facade. D'une manière générale, les utilisations xxxx que vous utilisez au-dessus de la classe sont toutes des façades. Pour plus de détails, voir le lien : https://www.jianshu.com/p/a96715975d4e

Alors, que dois-je faire si le service que je souhaite implémenter. n'est-il pas là ? Le nouveau service doit être enregistré et initialisé. Ce n'est que lorsqu'il est enregistré dans le conteneur que le conteneur peut l'appeler. Ce travail est implémenté par le fournisseur de services. Retour au sujet

Alors qu'est-ce que l'injection de dépendances : La méthode 1 du développeur définit une interface intermédiaire A. Cette interface A peut être stockée dans le constructeur de la classe 1 à laquelle appartient la méthode 1 sous forme de paramètres. injection.

Tant qu'il n'est pas produit en interne (comme l'initialisation, via la méthode d'usine dans le constructeur __construct, ou manuellement new), mais qu'il est injecté de l'extérieur sous forme de paramètres ou d'autres formes, il appartient à l'injection de dépendances

Comment fait-on l'injection de dépendance ? Très simple : $biller = new StripeBiller(new SmsNotifier);

Il s'agit d'une injection de dépendance. La classe de facturation StripeBiller n'a pas besoin de réfléchir à la manière de notifier l'utilisateur. Nous lui transmettons directement une instance de la classe d'implémentation de notification SmsNotifier

. Du point de vue du code, il ne s'agit peut-être que d'un changement mineur, mais l'introduction de ce modèle de conception donnera certainement un nouveau look à l'ensemble de votre architecture d'application : parce que les limites de responsabilité des classes sont clairement spécifiées, la communication entre les différentes couches et services est implémentée. Avec le découplage, votre code devient plus facile à maintenir ; de plus, du point de vue de la programmation orientée interface, le code devient plus facile à tester. Il suffit d'injecter des dépendances via la simulation, et les tests entre différentes classes peuvent être complètement isolés.

[Recommandations associées : tutoriel vidéo laravel]

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!