


Interprétation du conteneur de service Laravel (IocContainer)
Cet article présente principalement l'interprétation du conteneur de service Laravel (IocContainer), qui a une certaine valeur de référence. Maintenant, je le partage avec tout le monde. Les amis dans le besoin peuvent s'y référer
Le cœur de Laravel est IocContainer, document Il est appelé "conteneur de services". Le conteneur de services est un outil puissant pour gérer les dépendances de classe et effectuer l'injection de dépendances. Les modules fonctionnels de Laravel tels que Route, Eloquent ORM, Request, Response, etc. sont en fait liés à Fourni par le noyau. -modules de classes indépendants, ces classes sont en fait responsables du conteneur de services laravel de l'enregistrement à l'instanciation et finalement utilisées par nous.
Si vous n'avez pas une idée précise de ce qu'est un conteneur de service, je vous recommande un article de blog pour connaître les tenants et les aboutissants du conteneur de service : le conteneur de service magique de laravel
Il y a deux concepts dans le conteneur de service : l'inversion de contrôle (IOC) et l'injection de dépendances (DI) :
L'injection de dépendances et l'inversion de contrôle sont des descriptions différentes de la même chose, et elles la décrivent sous des perspectives différentes . L'injection de dépendances est décrite du point de vue de l'application. L'application s'appuie sur le conteneur pour créer et injecter les ressources externes dont elle a besoin. L'inversion de contrôle est décrite du point de vue du conteneur. Le conteneur contrôle l'application et le conteneur injecte à l'envers les ressources externes requises par l'application dans l'application.
Dans Laravel, le framework lie ses différents services au conteneur de services. Nous pouvons également lier des services personnalisés au conteneur. Lorsqu'une application doit utiliser un certain service, le conteneur de services résoudra le service et résoudra automatiquement les dépendances entre les services, puis le remettra à l'application pour utilisation.
Cet article expliquera comment la liaison et l'analyse des services sont implémentées dans Laravel
Liaison de service
Les méthodes couramment utilisées pour lier les services aux conteneurs sont instance , bind, singleton, alias. Examinons-les séparément.
instance
lie un objet existant au conteneur de service. Lorsque le service est ensuite résolu par nom, le conteneur renverra toujours l'instance liée.
$api = new HelpSpot\API(new HttpClient); $this->app->instance('HelpSpot\Api', $api);
L'objet sera enregistré dans l'attribut $instnces du conteneur de service
[ 'HelpSpot\Api' => $api//$api是API类的对象,这里简写了 ]
bind
Lier le service au conteneur de service
Il existe trois méthodes de liaison :
1.绑定自身 $this->app->bind('HelpSpot\API', null); 2.绑定闭包 $this->app->bind('HelpSpot\API', function () { return new HelpSpot\API(); });//闭包直接提供类实现方式 $this->app->bind('HelpSpot\API', function ($app) { return new HelpSpot\API($app->make('HttpClient')); });//闭包返回需要依赖注入的类 3. 绑定接口和实现 $this->app->bind('Illuminate\Tests\Container\IContainerContractStub', 'Illuminate\Tests\Container\ContainerImplementationStub');
Dans le premier cas, en fait, à l'intérieur de la méthode bind, une fermeture est générée pour le service via getClosure()
avant de lier le service. regardez le code source de la méthode bind.
public function bind($abstract, $concrete = null, $shared = false) { $abstract = $this->normalize($abstract); $concrete = $this->normalize($concrete); //如果$abstract为数组类似['Illuminate/ServiceName' => 'service_alias'] //抽取别名"service_alias"并且注册到$aliases[]中 //注意:数组绑定别名的方式在5.4中被移除,别名绑定请使用下面的alias方法 if (is_array($abstract)) { list($abstract, $alias) = $this->extractAlias($abstract); $this->alias($abstract, $alias); } $this->dropStaleInstances($abstract); if (is_null($concrete)) { $concrete = $abstract; } //如果只提供$abstract,则在这里为其生成concrete闭包 if (! $concrete instanceof Closure) { $concrete = $this->getClosure($abstract, $concrete); } $this->bindings[$abstract] = compact('concrete', 'shared'); if ($this->resolved($abstract)) { $this->rebound($abstract); } } protected function getClosure($abstract, $concrete) { // $c 就是$container,即服务容器,会在回调时传递给这个变量 return function ($c, $parameters = []) use ($abstract, $concrete) { $method = ($abstract == $concrete) ? 'build' : 'make'; return $c->$method($concrete, $parameters); }; }
bind enregistre le service dans l'attribut $bindings du conteneur de service comme ceci :
$bindings = [ 'HelpSpot\API' => [//闭包绑定 'concrete' => function ($app, $paramters = []) { return $app->build('HelpSpot\API'); }, 'shared' => false//如果是singleton绑定,这个值为true ] 'Illuminate\Tests\Container\IContainerContractStub' => [//接口实现绑定 'concrete' => 'Illuminate\Tests\Container\ContainerImplementationStub', 'shared' => false ] ]
singleton
public function singleton($abstract, $concrete = null) { $this->bind($abstract, $concrete, true); }
La méthode singleton est une variante de la méthode bind , liez une classe ou une interface qui ne doit être analysée qu'une seule fois au conteneur, puis le service renverra la même instance pour les appels ultérieurs au conteneur
alias
Register le service et l'alias de service vers le conteneur :
public function alias($abstract, $alias) { $this->aliases[$alias] = $this->normalize($abstract); }
La méthode alias a été utilisée dans la méthode de liaison mentionnée ci-dessus. Elle enregistrera la relation correspondante entre l'alias de service et la classe de service dans l'attribut $aliases du. conteneur de service.
Par exemple :
$this->app->alias('\Illuminate\ServiceName', 'service_alias');
Après avoir lié le service, vous pouvez analyser l'objet de service via
$this->app->make('service_alias');
lorsque vous l'utilisez, afin de ne pas avoir à écrire longtemps ceux lors de la création Le nom de la classe a été modifié et l'expérience d'utilisation de la méthode make a été grandement améliorée.
Analyse du service
make : analyse l'objet de service à partir du conteneur de service. Cette méthode reçoit le nom de la classe ou le nom de l'interface que vous souhaitez analyser en tant que paramètre
/** * Resolve the given type from the container. * * @param string $abstract * @param array $parameters * @return mixed */ public function make($abstract, array $parameters = []) { //getAlias方法会假定$abstract是绑定的别名,从$aliases找到映射的真实类型名 //如果没有映射则$abstract即为真实类型名,将$abstract原样返回 $abstract = $this->getAlias($this->normalize($abstract)); // 如果服务是通过instance()方式绑定的,就直接解析返回绑定的service if (isset($this->instances[$abstract])) { return $this->instances[$abstract]; } // 获取$abstract接口对应的$concrete(接口的实现) $concrete = $this->getConcrete($abstract); if ($this->isBuildable($concrete, $abstract)) { $object = $this->build($concrete, $parameters); } else { //如果时接口实现这种绑定方式,通过接口拿到实现后需要再make一次才能 //满足isBuildable的条件 ($abstract === $concrete) $object = $this->make($concrete, $parameters); } foreach ($this->getExtenders($abstract) as $extender) { $object = $extender($object, $this); } //如果服务是以singleton方式注册进来的则,把构建好的服务对象放到$instances里, //避免下次使用时重新构建 if ($this->isShared($abstract)) { $this->instances[$abstract] = $object; } $this->fireResolvingCallbacks($abstract, $object); $this->resolved[$abstract] = true; return $object; } protected function getConcrete($abstract) { if (! is_null($concrete = $this->getContextualConcrete($abstract))) { return $concrete; } // 如果是$abstract之前没有注册类实现到服务容器里,则服务容器会认为$abstract本身就是接口的类实现 if (! isset($this->bindings[$abstract])) { return $abstract; } return $this->bindings[$abstract]['concrete']; } protected function isBuildable($concrete, $abstract) { return $concrete === $abstract || $concrete instanceof Closure; }
. Pass Après avoir trié la méthode make, nous avons constaté que la fonction de la méthode build est de construire l'objet de service analysé. Jetons un coup d'œil au processus spécifique de construction de l'objet. (La réflexion des classes PHP est utilisée pendant le processus de construction pour implémenter l'injection de dépendances des services)
public function build($concrete, array $parameters = []) { // 如果是闭包直接执行闭包并返回(对应闭包绑定) if ($concrete instanceof Closure) { return $concrete($this, $parameters); } // 使用反射ReflectionClass来对实现类进行反向工程 $reflector = new ReflectionClass($concrete); // 如果不能实例化,这应该是接口或抽象类,再或者就是构造函数是private的 if (! $reflector->isInstantiable()) { if (! empty($this->buildStack)) { $previous = implode(', ', $this->buildStack); $message = "Target [$concrete] is not instantiable while building [$previous]."; } else { $message = "Target [$concrete] is not instantiable."; } throw new BindingResolutionException($message); } $this->buildStack[] = $concrete; // 获取构造函数 $constructor = $reflector->getConstructor(); // 如果构造函数是空,说明没有任何依赖,直接new返回 if (is_null($constructor)) { array_pop($this->buildStack); return new $concrete; } // 获取构造函数的依赖(形参),返回一组ReflectionParameter对象组成的数组表示每一个参数 $dependencies = $constructor->getParameters(); $parameters = $this->keyParametersByArgument( $dependencies, $parameters ); // 构建构造函数需要的依赖 $instances = $this->getDependencies( $dependencies, $parameters ); array_pop($this->buildStack); return $reflector->newInstanceArgs($instances); } //获取依赖 protected function getDependencies(array $parameters, array $primitives = []) { $dependencies = []; foreach ($parameters as $parameter) { $dependency = $parameter->getClass(); // 某一依赖值在$primitives中(即build方法的$parameters参数)已提供 // $parameter->name返回参数名 if (array_key_exists($parameter->name, $primitives)) { $dependencies[] = $primitives[$parameter->name]; } elseif (is_null($dependency)) { // 参数的ReflectionClass为null,说明是基本类型,如'int','string' $dependencies[] = $this->resolveNonClass($parameter); } else { // 参数是一个类的对象, 则用resolveClass去把对象解析出来 $dependencies[] = $this->resolveClass($parameter); } } return $dependencies; } //解析出依赖类的对象 protected function resolveClass(ReflectionParameter $parameter) { try { // $parameter->getClass()->name返回的是类名(参数在typehint里声明的类型) // 然后递归继续make(在make时发现依赖类还有其他依赖,那么会继续make依赖的依赖 // 直到所有依赖都被解决了build才结束) return $this->make($parameter->getClass()->name); } catch (BindingResolutionException $e) { if ($parameter->isOptional()) { return $parameter->getDefaultValue(); } throw $e; } }
Le conteneur de services est le cœur de laravel. Il peut nous aider à résoudre les interdépendances entre les objets grâce à l'injection de dépendances. et grâce à l'inversion de contrôle, il est laissé à l'extérieur de définir des comportements spécifiques (Route, Eloquent, ce sont des modules externes, et ils définissent leurs propres spécifications comportementales. Le conteneur de services est responsable de ces classes de l'enregistrement à l'instanciation pour votre utilisation).
Pour qu'une classe soit extraite par un conteneur, elle doit d'abord être enregistrée auprès du conteneur. Puisque Laravel appelle ce conteneur un conteneur de services, si nous avons besoin d'un service, nous devons d'abord enregistrer et lier le service au conteneur. Ensuite, la chose qui fournit le service et lie le service au conteneur est le fournisseur de services (ServiceProvider). Le fournisseur de services est principalement divisé en deux parties, registre (enregistrement) et démarrage (démarrage, initialisation). En raison de problèmes d'espace, veuillez consulter une autre interprétation de base de Laravel - Fournisseur de services (ServiceProvider) pour le contenu du fournisseur de services Laravel.
Ce qui précède représente l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'étude de chacun. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois !
Recommandations associées :
Demande d'interprétation de Laravel Core
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!

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

AI Hentai Generator
Générez AI Hentai gratuitement.

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Les dernières versions de Laravel 9 et CodeIgniter 4 fournissent des fonctionnalités et des améliorations mises à jour. Laravel9 adopte l'architecture MVC et fournit des fonctions telles que la migration de bases de données, l'authentification et le moteur de modèles. CodeIgniter4 utilise l'architecture HMVC pour fournir le routage, l'ORM et la mise en cache. En termes de performances, le modèle de conception basé sur le fournisseur de services de Laravel9 et le framework léger de CodeIgniter4 lui confèrent d'excellentes performances. Dans les applications pratiques, Laravel9 convient aux projets complexes qui nécessitent de la flexibilité et des fonctions puissantes, tandis que CodeIgniter4 convient au développement rapide et aux petites applications.

Comparez les capacités de traitement des données de Laravel et CodeIgniter : ORM : Laravel utilise EloquentORM, qui fournit un mappage relationnel classe-objet, tandis que CodeIgniter utilise ActiveRecord pour représenter le modèle de base de données en tant que sous-classe de classes PHP. Générateur de requêtes : Laravel dispose d'une API de requêtes chaînées flexible, tandis que le générateur de requêtes de CodeIgniter est plus simple et basé sur des tableaux. Validation des données : Laravel fournit une classe Validator qui prend en charge les règles de validation personnalisées, tandis que CodeIgniter a moins de fonctions de validation intégrées et nécessite un codage manuel des règles personnalisées. Cas pratique : l'exemple d'enregistrement d'utilisateur montre Lar

Laravel - Artisan Commands - Laravel 5.7 est livré avec une nouvelle façon de traiter et de tester de nouvelles commandes. Il inclut une nouvelle fonctionnalité de test des commandes artisanales et la démonstration est mentionnée ci-dessous ?

Pour les débutants, CodeIgniter a une courbe d'apprentissage plus douce et moins de fonctionnalités, mais couvre les besoins de base. Laravel offre un ensemble de fonctionnalités plus large mais a une courbe d'apprentissage légèrement plus raide. En termes de performances, Laravel et CodeIgniter fonctionnent bien. Laravel dispose d'une documentation plus complète et d'un support communautaire actif, tandis que CodeIgniter est plus simple, léger et possède de solides fonctionnalités de sécurité. Dans le cas pratique de la création d'une application de blog, EloquentORM de Laravel simplifie la manipulation des données, tandis que CodeIgniter nécessite une configuration plus manuelle.

Lors du choix d'un framework pour de grands projets, Laravel et CodeIgniter ont chacun leurs propres avantages. Laravel est conçu pour les applications d'entreprise, offrant une conception modulaire, une injection de dépendances et un ensemble de fonctionnalités puissantes. CodeIgniter est un framework léger plus adapté aux projets de petite et moyenne taille, mettant l'accent sur la rapidité et la facilité d'utilisation. Pour les grands projets avec des exigences complexes et un grand nombre d'utilisateurs, la puissance et l'évolutivité de Laravel sont plus adaptées. Pour les projets simples ou les situations avec des ressources limitées, les capacités de développement légères et rapides de CodeIgniter sont plus idéales.

Pour les petits projets, Laravel convient aux projets plus importants qui nécessitent des fonctionnalités et une sécurité élevées. CodeIgniter convient aux très petits projets qui nécessitent légèreté et facilité d'utilisation.

L'architecture des microservices utilise des frameworks PHP (tels que Symfony et Laravel) pour implémenter des microservices et suit les principes RESTful et les formats de données standard pour concevoir des API. Les microservices communiquent via des files d'attente de messages, des requêtes HTTP ou gRPC et utilisent des outils tels que Prometheus et ELKStack pour la surveillance et le dépannage.

En comparant le moteur de modèles Blade de Laravel et le moteur de modèles Twig de CodeIgniter, choisissez en fonction des besoins du projet et de vos préférences personnelles : Blade est basé sur la syntaxe MVC, qui encourage une bonne organisation du code et un héritage de modèles. Twig est une bibliothèque tierce qui offre une syntaxe flexible, des filtres puissants, une prise en charge étendue et un bac à sable de sécurité.
