Avant-propos
Pour être honnête, le premier matin, le patron m'a demandé de lire le manuel du framework Laravel, j'étais ... Je suis très désespéré car je n'y ai vraiment pas été exposé. Pour un salaud comme moi, le seuil d'entrée pour Laravel est effectivement un peu élevé, mais je dois quand même serrer les dents et continuer à lire (même si je le fais). je n'y comprends toujours pas grand chose, et je ne comprends pas encore).
Plus tard, je me suis progressivement familiarisé avec Laravel en me basant sur le code du projet de l'entreprise, mais il restait encore sur certaines fonctions superficielles, comme l'injection de dépendances, les opérations ORM, l'authentification des utilisateurs et d'autres opérations liées à la logique métier de mon projet. pour Certaines architectures de base, comme les fournisseurs de services, les conteneurs de services, les middlewares, Redis, etc., qui doivent être mises en place dès le début, n'ont pas été réellement exploitées par moi (car le patron l'a déjà fait depuis le début), donc c'est quand même un peu déroutant de lire le manuel bête.
Alors, quand j'ai du temps libre, je parcoure les forums et je recherche sur Google pour trouver de nombreuses introductions à l'architecture de base de Laravel et comment l'utiliser (ce sera plus facile à comprendre si vous lisez le manuel après l'avoir lu ici). est un guide Je pense que l'enseignement sur le site est bon pour enregistrer l'apprentissage de l'architecture de base de Laravel
Adresse du site Web : https://laraweb.net/ C'est un site Web japonais, je pense qu'il convient tout à fait aux novices. le contenu est traduit à l'aide du navigateur. Ce n'est pas grave, après tout, c'est facile à comprendre lorsque vous le traduisez du japonais
À propos du conteneur de service
Le manuel le présente comme ceci : Le conteneur de service Laravel est utilisé pour gérer les dépendances de classe et effectuer un outil d'injection de dépendances. Le terme sophistiqué d'injection de dépendances signifie essentiellement que les dépendances d'une classe sont "injectées" dans la classe via le constructeur ou, dans certains cas, la méthode "setter". . . . . . (Je ne comprends vraiment pas ce que cela signifie)
Un conteneur de services est un mécanisme utilisé pour gérer l'instanciation de classes (services). Voyez directement comment utiliser le conteneur de service
1. Enregistrez la classe dans le conteneur de service (bind)
$this->app->bind('sender','MailSender');
//$this->app成为服务容器。
2. Générez la classe à partir du conteneur de service (make)
$sender = $this->app->make('sender');
//从服务容器（$this->app）创建一个sender类。
在这种情况下，将返回MailSender的实例。
Il s'agit de l'utilisation la plus simple des conteneurs de services, ce qui suit est une introduction détaillée aux conteneurs de services
(Référence principale : https://www.cnblogs.com/lyzg/...)
Basique compréhension des conteneurs Laravel
Initialement, le fichier index.php charge l'autochargeur défini par la build Composer, puis récupère une instance de l'application Laravel à partir du script bootstrap/app.php. La première action entreprise par Laravel lui-même est de créer une instance du conteneur d'application/service.
$app = new Illuminate\Foundation\Application( dirname(__DIR__) );
Ce fichier sera exécuté à chaque fois qu'une requête atteint le framework laravel. Le $app créé est l'instance d'application du framework laravel, qui est unique tout au long du cycle de vie de la requête. Laravel fournit de nombreux services, notamment l'authentification, la base de données, le cache, la file d'attente de messages, etc. $app, en tant qu'outil de gestion de conteneurs, est responsable de l'instanciation de presque tous les composants du service et de la gestion du cycle de vie de l'instance. Lorsqu'une classe de service est nécessaire pour remplir une certaine fonction, il lui suffit de résoudre une instance de ce type via le conteneur. Du point de vue de l'utilisation finale, la gestion des instances de service par le conteneur Laravel comprend principalement les aspects suivants :
- Liaison et analyse de services
- Fournisseur de services gestion
- Le rôle des alias
- Injection de dépendances
Comprendre d'abord comment obtenir le conteneur instance dans le code, puis apprenez les quatre clés ci-dessus
Comment obtenir l'instance de conteneur dans le code
La première est
$app = app(); //app这个辅助函数定义在\vendor\laravel\framework\src\Illuminate\Foundation\helper.php 里面，，这个文件定义了很多help函数，并且会通过composer自动加载到项目中。 所以，在参与http请求处理的任何代码位置都能够访问其中的函数，比如app()。
La seconde est
Route::get('/', function () {
dd(App::basePath());
return '';
});
//这个其实是用到Facade，中文直译貌似叫门面，在config/app.php中，
有一节数组aliases专门用来配置一些类型的别名，第一个就是'App' => Illuminate\Support\Facades\App::class,
具体的Google一下laravel有关门面的具体实现方式 La troisième option consiste à utiliser $this->app directement dans le fournisseur de services. Le fournisseur de services sera présenté plus tard, mais il vient juste d'être présenté maintenant. Étant donné que les classes de fournisseur de services sont instanciées par le conteneur laravel, ces classes héritent d'IlluminateSupportServiceProvider, qui définit un attribut d'instance $app :
abstract class ServiceProvider
{
protected $app;
Lorsque laravel instancie le fournisseur de services, laravel le fera. L'instance du conteneur est injectée dans ce $app . Ainsi, chez le fournisseur de services, nous pouvons toujours accéder à l'instance de conteneur Laravel via $this->$app, sans utiliser la fonction app() ou App Facade.
Comment comprendre la liaison et l'analyse des services
Pour comprendre à un niveau superficiel, puisque le conteneur est utilisé pour stocker des objets, il doit y avoir un processus de stockage et de suppression d'objets. Le processus de stockage et de récupération de cet objet est appelé liaison de service et analyse dans Laravel.
app()->bind('service', 'this is service1');
app()->bind('service2', [
'hi' => function(){
//say hi
}
]);
class Service {
}
app()->bind('service3', function(){
return new Service();
});
Il existe également un singleton de liaison singleton, qui est un cas particulier de liaison (le troisième paramètre est vrai. L'objet lié au conteneur ne sera analysé qu'une seule fois et les appels suivants renverront le même exemple). de
public function singleton($abstract, $concrete = null)
{
$this->bind($abstract, $concrete, true);
}
在绑定的时候，我们可以直接绑定已经初始化好的数据（基本类型、数组、对象实例），还可以用匿名函数来绑定。用匿名函数的好处在于，这个服务绑定到容器以后，并不会立即产生服务最终的对象，只有在这个服务解析的时候，匿名函数才会执行，此时才会产生这个服务对应的服务实例。
实际上，当我们使用singleton，bind方法以及数组形式，（这三个方法是后面要介绍的绑定的方法），进行服务绑定的时候，如果绑定的服务形式，不是一个匿名函数，也会在laravel内部用一个匿名函数包装起来，这样的话， 不轮绑定什么内容，都能做到前面介绍的懒初始化的功能，这对于容器的性能是有好处的。这个可以从bind的源码中看到一些细节：
if (! $concrete instanceof Closure) {
$concrete = $this->getClosure($abstract, $concrete);
}
看看bind的底层代码
public function bind($abstract, $concrete = null, $shared = false)
第一个参数服务绑定名称，第二个参数服务绑定的结果（也就是闭包，得到实例），第三个参数就表示这个服务是否在多次解析的时候，始终返回第一次解析出的实例（也就是单例绑定singleton）。
服务绑定还可以通过数组的方式：
app()['service'] = function(){
return new Service();
};
绑定大概就这些，接下来看解析，也就是取出来用
$service= app()->make('service');
这个方法接收两个参数，第一个是服务的绑定名称和服务绑定名称的别名，如果是别名，那么就会根据服务绑定名称的别名配置，找到最终的服务绑定名称，然后进行解析；第二个参数是一个数组，最终会传递给服务绑定产生的闭包。
看源码：
/**
* Resolve the given type from the container.
*
* @param string $abstract
* @param array $parameters
* @return mixed
*/
public function make($abstract, array $parameters = [])
{
return $this->resolve($abstract, $parameters);
}
/**
* Resolve the given type from the container.
*
* @param string $abstract
* @param array $parameters
* @return mixed
*/
protected function resolve($abstract, $parameters = [])
{
$abstract = $this->getAlias($abstract);
$needsContextualBuild = ! empty($parameters) || ! is_null(
$this->getContextualConcrete($abstract)
);
// If an instance of the type is currently being managed as a singleton we'll
// just return an existing instance instead of instantiating new instances
// so the developer can keep using the same objects instance every time.
if (isset($this->instances[$abstract]) && ! $needsContextualBuild) {
return $this->instances[$abstract];
}
$this->with[] = $parameters;
$concrete = $this->getConcrete($abstract);
// We're ready to instantiate an instance of the concrete type registered for
// the binding. This will instantiate the types, as well as resolve any of
// its "nested" dependencies recursively until all have gotten resolved.
if ($this->isBuildable($concrete, $abstract)) {
$object = $this->build($concrete);
} else {
$object = $this->make($concrete);
}
// If we defined any extenders for this type, we'll need to spin through them
// and apply them to the object being built. This allows for the extension
// of services, such as changing configuration or decorating the object.
foreach ($this->getExtenders($abstract) as $extender) {
$object = $extender($object, $this);
}
// If the requested type is registered as a singleton we'll want to cache off
// the instances in "memory" so we can return it later without creating an
// entirely new instance of an object on each subsequent request for it.
if ($this->isShared($abstract) && ! $needsContextualBuild) {
$this->instances[$abstract] = $object;
}
$this->fireResolvingCallbacks($abstract, $object);
// Before returning, we will also set the resolved flag to "true" and pop off
// the parameter overrides for this build. After those two things are done
// we will be ready to return back the fully constructed class instance.
$this->resolved[$abstract] = true;
array_pop($this->with);
return $object;
}
第一步：
$needsContextualBuild = ! empty($parameters) || ! is_null( $this->getContextualConcrete($abstract) );
该方法主要是区分，解析的对象是否有参数，如果有参数，还需要对参数做进一步的分析，因为传入的参数，也可能是依赖注入的，所以还需要对传入的参数进行解析；这个后面再分析。
第二步：
if (isset($this->instances[$abstract]) && ! $needsContextualBuild) {
return $this->instances[$abstract];
}
如果是绑定的单例，并且不需要上面的参数依赖。我们就可以直接返回 $this->instances[$abstract]。
第三步：
$concrete = $this->getConcrete($abstract);
...
/**
* Get the concrete type for a given abstract.
*
* @param string $abstract
* @return mixed $concrete
*/
protected function getConcrete($abstract)
{
if (! is_null($concrete = $this->getContextualConcrete($abstract))) {
return $concrete;
}
// If we don't have a registered resolver or concrete for the type, we'll just
// assume each type is a concrete name and will attempt to resolve it as is
// since the container should be able to resolve concretes automatically.
if (isset($this->bindings[$abstract])) {
return $this->bindings[$abstract]['concrete'];
}
return $abstract;
}
这一步主要是先从绑定的上下文找，是不是可以找到绑定类；如果没有，则再从 $bindings[] 中找关联的实现类；最后还没有找到的话，就直接返回 $abstract 本身。
// We're ready to instantiate an instance of the concrete type registered for
// the binding. This will instantiate the types, as well as resolve any of
// its "nested" dependencies recursively until all have gotten resolved.
if ($this->isBuildable($concrete, $abstract)) {
$object = $this->build($concrete);
} else {
$object = $this->make($concrete);
}
...
/**
* Determine if the given concrete is buildable.
*
* @param mixed $concrete
* @param string $abstract
* @return bool
*/
protected function isBuildable($concrete, $abstract)
{
return $concrete === $abstract || $concrete instanceof Closure;
}
如果之前找到的 $concrete 返回的是 $abstract 值，或者 $concrete 是个闭包，则执行 $this->build($concrete)，否则，表示存在嵌套依赖的情况，则采用递归的方法执行 $this->make($concrete)，直到所有的都解析完为止。
$this->build($concrete)
/**
* Instantiate a concrete instance of the given type.
*
* @param string $concrete
* @return mixed
*
* @throws \Illuminate\Contracts\Container\BindingResolutionException
*/
public function build($concrete)
{
// If the concrete type is actually a Closure, we will just execute it and
// hand back the results of the functions, which allows functions to be
// used as resolvers for more fine-tuned resolution of these objects.
// 如果传入的是闭包，则直接执行闭包函数，返回结果
if ($concrete instanceof Closure) {
return $concrete($this, $this->getLastParameterOverride());
}
// 利用反射机制，解析该类。
$reflector = new ReflectionClass($concrete);
// If the type is not instantiable, the developer is attempting to resolve
// an abstract type such as an Interface of Abstract Class and there is
// no binding registered for the abstractions so we need to bail out.
if (! $reflector->isInstantiable()) {
return $this->notInstantiable($concrete);
}
$this->buildStack[] = $concrete;
// 获取构造函数
$constructor = $reflector->getConstructor();
// If there are no constructors, that means there are no dependencies then
// we can just resolve the instances of the objects right away, without
// resolving any other types or dependencies out of these containers.
// 如果没有构造函数，则表明没有传入参数，也就意味着不需要做对应的上下文依赖解析。
if (is_null($constructor)) {
// 将 build 过程的内容 pop，然后直接构造对象输出。
array_pop($this->buildStack);
return new $concrete;
}
// 获取构造函数的参数
$dependencies = $constructor->getParameters();
// Once we have all the constructor's parameters we can create each of the
// dependency instances and then use the reflection instances to make a
// new instance of this class, injecting the created dependencies in.
// 解析出所有上下文依赖对象，带入函数，构造对象输出
$instances = $this->resolveDependencies(
$dependencies
);
array_pop($this->buildStack);
return $reflector->newInstanceArgs($instances);
}
上面这一段有关解析make的介绍主要参考：
coding01:看 Laravel 源代码了解 Container
这一篇就主要学习laravel的服务容器以及它的绑定和解析，虽然目前能力无法对框架源码每一个地方都弄懂，但通过这几篇优秀的文章，我将其进行整理结合，这过程让我更加理解laravel的一些核心内容，起码别人问起来我多多少少能说出一些，这就是进步。
后面有关服务提供者，依赖注入，中间件等内容的学习将放在后续的博客文章中,欢迎看看我的其他博客文章：https://zgxxx.github.io/。
以上相关知识的引用已经注明出处，若有侵权，请联系我，感谢这些优秀文章的作者