Explication détaillée et cas : Introduction au cycle de vie des requêtes Laravel

Cet article vous apporte des connaissances pertinentes sur le cycle de déclaration des demandes de laravel Le cycle de vie des demandes comporte différents termes, tels que chargeur automatique, noyau, fournisseur de services, demande de planification et routage, etc. J'espère qu'il sera utile à tout le monde. .

Laravel est un framework PHP puissant Lorsque vous apprenez le framework Laravel, le cycle de vie des requêtes Laravel est le meilleur point de départ. Cet article présentera ce qui se passe entre la réception d'une requête HTTP et la réponse dans Laravel. Une étude approfondie du cycle de vie des requêtes nous aidera à comprendre la structure de Laravel. (Basé sur Laravel 8)

Il existe différents termes pour le cycle de vie des demandes, tels que chargeur automatique, noyau, fournisseur de services, demande de répartition et routage, etc. Une fois que vous aurez compris toute la terminologie en détail, vous comprendrez mieux le framework et pourrez l'étendre avec différentes fonctionnalités à votre guise.

Aperçu du cycle de vie des requêtes Laravel

La première étape

Charger les dépendances du projet et créer une instance d'application Laravel

Le point d'entrée pour toutes les requêtes dans l'application Laravel est public/index.php documenter. Toutes les requêtes sont dirigées vers ce fichier par la configuration de votre serveur Web (Apache/Nginx). Ce fichier index.php ne contient pas beaucoup de code. Au lieu de cela, c'est le point de départ pour charger le reste du cadre. public/index.php 文件。所有请求都由你的 web 服务器（Apache/Nginx）配置定向到此文件。那个 index.php 文件不包含太多代码。相反，它是加载框架其余部分的起点。

# 1、加载项目依赖require __DIR__.'/../vendor/autoload.php';
$app = require_once __DIR__.'/../bootstrap/app.php';

该 index.php 文件将加载 Composer 生成的自动加载器定义，然后从 bootstrap/app.php 中检索 Laravel 应用程序的实例。

bootstrap/app.php:

<?php

    # 2、创建应用实例
    $app = new Illuminate\Foundation\Application(
        $_ENV[&#39;APP_BASE_PATH&#39;] ?? dirname(__DIR__)
    );

    # 3、完成内核绑定
    $app->singleton(
        Illuminate\Contracts\Http\Kernel::class,
        App\Http\Kernel::class
    );

    $app->singleton(
        Illuminate\Contracts\Console\Kernel::class,
        App\Console\Kernel::class
    );

    $app->singleton(
        Illuminate\Contracts\Debug\ExceptionHandler::class,
        App\Exceptions\Handler::class
    );

    return $app;

之后，它将引导 Laravel 框架使用并生成应用程序实例。

public/index.php：

# 4、接收请求并响应$kernel = $app->make(Kernel::class);// 处理请求$response = tap($kernel->handle(
	// 创建请求实例
    $request = Request::capture()// 发送响应))->send();$kernel->terminate($request, $response);

一旦应用程序实例生成，传入请求将由内核处理。

HTTP 或 Console 内核

接下来，传入请求被发送到 HTTP 内核还是 Console 内核，具体取决于进入应用的请求类型。这两个内核充当所有请求流经的中心位置。现在，让我们只关注 HTTP 内核，它位于 app/Http/Kernel.php 中。

HTTP 内核扩展了 IlluminateFoundationHttpkernel 类，该类定义了一个将在执行请求之前运行的 bootstrappers 数组。这些引导程序用来配置异常处理、配置日志、检测应用程序环境 ，并执行在实际处理请求之前需要完成的其他任务。通常情况下，你不需要在意这些配置。

HTTP 内核还定义了一个 HTTP 中间件列表，所有请求在被应用程序处理之前必须通过这些中间件。这些中间件处理 HTTP 会话的读写、确定应用程序是否处于维护模式、验证 CSRF 令牌等。我们接下来会做详细的讨论。

HTTP 内核的 handle 方法的签名非常简单：它接收 Request 接口并返回 Response 接口。把内核想象成一个代表整个应用程序的大黑匣子。向它提供 HTTP 请求，它将返回 HTTP 响应。

通过配置中间件和其他功能，HTTP 内核还加载服务提供者。

服务提供器

最重要的内核引导操作之一是为应用程序加载 service providers。应用程序的所有服务提供程序都在 config/app.php 中的 providers 数组。

Laravel 将遍历这个提供者列表并实例化它们中的每一个。实例化提供程序后，将对所有提供程序调用 register方法。然后，一旦注册了所有提供程序，就会对每个提供程序调用boot 方法。

服务提供者负责引导框架的所有不同组件，如数据库、队列、验证和路由组件。基本上，Laravel 提供的每个主要功能都是由服务提供商引导和配置的。由于它们引导和配置框架提供的许多特性，服务提供者是整个 Laravel 引导过程中最重要的部分。

您可能想知道，为什么在对任何服务提供者调用 boot方法之前都要调用每个服务提供者的 register 方法。答案很简单。通过首先调用每个服务提供程序的 register 方法，服务提供者可能依赖于在执行 boot 方法时注册并可用的每个容器绑定。

服务提供者是引导 Laravel 应用程序的关键。应用程序实例被创建，服务提供者被注册，请求被交给引导的应用程序。真的就是这么简单！

牢牢掌握 Laravel 应用程序如何通过服务提供商构建和引导是非常有价值的。您的应用程序的默认服务提供者存储在该app/Providersrrreee

Le fichier index.php chargera la définition de l'autoloader générée par Composer puis récupérera l'instance de l'application Laravel depuis bootstrap/app.php.

bootstrap/app.php:🎜rrreee🎜Ensuite, il amorcera le framework Laravel pour utiliser et générer une instance d'application. 🎜🎜public/index.php : 🎜rrreee🎜Une fois l'instance d'application générée, les requêtes entrantes seront traitées par le noyau. 🎜🎜HTTP ou Console Kernel🎜🎜Ensuite, la requête entrante est envoyée soit au noyau HTTP, soit au noyau de console, selon le type de requête entrant dans l'application. Ces deux noyaux agissent comme un emplacement central par lequel transitent toutes les demandes. Pour l'instant, concentrons-nous uniquement sur le noyau HTTP, qui se trouve dans app/Http/Kernel.php. 🎜🎜Le noyau HTTP étend la classe IlluminateFoundationHttpkernel, qui définit un tableau de bootstrappers qui seront exécutés avant d'exécuter la requête. Ces bootstraps sont utilisés pour configurer la gestion des exceptions, configurer la journalisation, détecter l'environnement de l'application et effectuer d'autres tâches qui doivent être effectuées avant que la demande ne soit réellement traitée. Normalement, vous n'avez pas à vous soucier de ces configurations. 🎜🎜Le noyau HTTP définit également une liste de middlewares HTTP par lesquels toutes les requêtes doivent passer avant d'être traitées par l'application. Ces middlewares gèrent la lecture et l'écriture des sessions HTTP, déterminant si l'application est en mode maintenance, validant les jetons CSRF, etc. Nous en discuterons en détail ensuite. 🎜🎜La signature de la méthode handle du noyau HTTP est très simple : elle reçoit l'interface Request et renvoie l'interface Response. Considérez le noyau comme une grande boîte noire qui représente l'ensemble de l'application. Donnez-lui une requête HTTP et il renverra une réponse HTTP. 🎜🎜Le noyau HTTP charge également les fournisseurs de services en configurant le middleware et d'autres fonctions. 🎜🎜Fournisseurs de services🎜🎜L'une des opérations de démarrage du noyau les plus importantes consiste à charger les fournisseurs de services pour l'application. Tous les fournisseurs de services pour l'application se trouvent dans le tableau providers dans config/app.php. 🎜🎜Laravel parcourra cette liste de fournisseurs et instanciera chacun d'entre eux. Une fois qu'un fournisseur est instancié, la méthode register est appelée sur tous les fournisseurs. Ensuite, une fois tous les fournisseurs enregistrés, la méthode boot est appelée sur chaque fournisseur. 🎜🎜Les fournisseurs de services sont responsables de l'amorçage de tous les différents composants du framework tels que les composants de base de données, de file d'attente, de validation et de routage. Fondamentalement, chaque fonctionnalité majeure fournie par Laravel est démarrée et configurée par un fournisseur de services. Les fournisseurs de services constituent la partie la plus importante de l'ensemble du processus d'amorçage de Laravel en raison des nombreuses fonctionnalités fournies par leur cadre d'amorçage et de configuration. 🎜🎜Vous vous demandez peut-être pourquoi la méthode register de chaque fournisseur de services est appelée avant d'appeler la méthode boot sur n'importe quel fournisseur de services. La réponse est simple. En appelant d'abord la méthode d'enregistrement de chaque fournisseur de services, le fournisseur de services peut s'appuyer sur le fait que chaque liaison de conteneur est enregistrée et disponible lorsque la méthode de démarrage est exécutée. 🎜🎜Les fournisseurs de services sont la clé du démarrage de votre application Laravel. L'instance d'application est créée, le fournisseur de services est enregistré et la demande est transmise à l'application d'amorçage. C'est vraiment aussi simple que ça ! 🎜🎜Avoir une solide compréhension de la manière dont les applications Laravel sont créées et démarrées par l'intermédiaire de fournisseurs de services est extrêmement précieux. Les fournisseurs de services par défaut de votre application sont stockés dans le répertoire app/Providers. 🎜🎜Par défaut, AppServiceProvider est vide. Cette procédure est un bon endroit pour ajouter les propres liaisons d'amorçage et de conteneur de service de votre application. Pour les applications volumineuses, vous souhaiterez peut-être créer plusieurs fournisseurs de services, chacun fournissant des conseils plus précis pour les services spécifiques utilisés par votre application. 🎜

Une fois l'application démarrée et tous les fournisseurs de services enregistrés et démarrés, les demandes sont transmises au routeur pour expédition.

Routing

L'un des fournisseurs de services les plus importants dans une application est AppProvidersRouteServiceProvider. Ce fournisseur de services charge les fichiers de routes contenus dans le répertoire routes de l'application. AppProvidersRouteServiceProvider。此服务提供程序加载应用程序的 routes 目录中包含的路由文件。

路由器将请求发送到路由或控制器，并运行任何路由特定的中间件。

中间件为过滤或检查进入应用程序的 HTTP 请求提供了一种方便的机制。例如，Laravel 包含一个这样的中间件，用于验证应用程序的用户是否经过身份验证。如果用户未通过身份验证，中间件将用户重定向到登录页。但是，如果用户经过身份验证，中间件将允许请求进一步进入应用程序。一些中间件被分配给应用程序中的所有路由，比如那些在 HTTP 内核的 $middleware属性中定义的路由，而一些只被分配给特定的路由或路由组。您可以通过阅读完整的 中间件 文档来了解更多关于中间件的信息。

如果请求通过了所有匹配路由分配的中间件，则将 HTTP 请求定向到控制器或通过省略控制器直接返回视图或响应

控制器

控制器 app/Http/Controllers/ 执行特定操作并将数据发送到视图。

视图

视图 resources/views/ 适当地格式化数据，提供 HTTP 响应。

最后

一旦路由或控制器方法返回一个响应，该响应将通过路由的中间件返回，从而使应用程序有机会修改或检查传出的响应。

通常，不会只从路由操作中返回简单的字符串或数组。而是返回完整的 IlluminateHttpResponse 实例或视图。

Response 实例派生自 SymfonyComponentHttpFoundationResponse 类，它提供了许多构造 HTTP 响应的方法。

最后，一旦响应通过中间件传回，HTTP 内核的 handle 方法将返回响应对象，并且index.php

Le routeur envoie la demande à une route ou à un contrôleur et exécute tout middleware spécifique à la route.

Le middleware fournit un mécanisme pratique pour filtrer ou inspecter les requêtes HTTP entrant dans votre application. Par exemple, Laravel inclut un middleware qui vérifie que les utilisateurs de votre application sont authentifiés. Si l'utilisateur n'est pas authentifié, le middleware redirige l'utilisateur vers la page de connexion. Cependant, si l'utilisateur est authentifié, le middleware autorisera la requête plus loin dans l'application. Certains middlewares sont affectés à toutes les routes de l'application, comme ceux définis dans l'attribut $middleware du noyau HTTP, tandis que d'autres sont affectés uniquement à des routes ou groupes de routes spécifiques. Vous pouvez en savoir plus sur le middleware en lisant la documentation complète du middleware.

Dirigez la requête HTTP vers le contrôleur ou renvoyez la vue ou la réponse directement en omettant le contrôleur si la requête passe tous les middlewares attribués par la route correspondante

Contrôleur 🎜🎜Contrôleur app/Http/Controllers/ Effectue une opération spécifique et envoie des données à la vue. 🎜🎜Views🎜🎜Views <code>resources/views/ Formatez les données de manière appropriée, en fournissant des réponses HTTP. 🎜🎜Enfin🎜🎜Une fois qu'une méthode de route ou de contrôleur renvoie une réponse, cette réponse est renvoyée via le middleware de la route, donnant à l'application la possibilité de modifier ou d'inspecter la réponse sortante. 🎜🎜Normalement, vous ne renverrez pas simplement une simple chaîne ou un tableau à partir d'une opération de routage. Au lieu de cela, une instance ou une vue IlluminateHttpResponse complète est renvoyée. 🎜🎜Les instances de réponse sont dérivées de la classe SymfonyComponentHttpFoundationResponse, qui fournit de nombreuses méthodes pour construire des réponses HTTP. 🎜🎜Enfin, une fois la réponse renvoyée via le middleware, la méthode handle du noyau HTTP renvoie l'objet de réponse et le fichier index.php appelle la méthode d'envoi sur la réponse renvoyée. La méthode send envoie le contenu de la réponse au navigateur Web de l'utilisateur. 🎜🎜À ce stade, nous avons terminé toutes les étapes de tout le cycle de vie de la requête Laravel ! 🎜🎜【Recommandation associée : 🎜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!