Introduction
Utiliser un outil dans le monde réel est plus rassurant lorsqu’on comprend son fonctionnement. Il en va de même pour le développement d’applications : comprendre le fonctionnement de vos outils vous rend plus productif et confiant. Cette page présente à haut niveau le fonctionnement du framework Laravel. Une bonne compréhension du framework dans son ensemble démystifie la « magie » et renforce votre confiance pour construire vos applications.Cycle de vie d’une requête HTTP
Vue d’ensemble
Première étape
Le point d’entrée de toute requête vers une application Laravel estpublic/index.php. Toutes les requêtes y sont redirigées par la configuration du serveur web (Apache / Nginx). Ce fichier contient peu de code : c’est le point de départ pour charger le reste du framework.
index.php charge les définitions d’autoloader générées par Composer, puis récupère l’instance de l’application Laravel depuis bootstrap/app.php. La première chose que fait Laravel est de créer l’instance de l’application / conteneur de services.
Kernel HTTP
Ensuite, la requête reçue est envoyée au kernel HTTP (Illuminate\Foundation\Http\Kernel) via la méthode handleRequest de l’instance de l’application.
Le kernel HTTP définit un tableau de bootstrappers exécutés avant que la requête ne soit traitée. Ils s’occupent de :
- Configurer la gestion des erreurs
- Configurer les logs
- Détecter l’environnement de l’application
- Effectuer d’autres tâches préalables au traitement
handle du kernel HTTP est simple : elle reçoit une Request et retourne une Response. Considérez le kernel comme une grande boîte noire représentant l’ensemble de votre application. Vous lui donnez une requête HTTP, elle vous rend une réponse HTTP.
Service providers
L’une des opérations les plus importantes du kernel est de charger les service providers. Ils sont responsables de l’initialisation des composants du framework : base de données, files d’attente, validation, routage, etc. Laravel itère sur la liste des providers, en crée une instance de chacun. Puis la méthoderegister de tous les providers est appelée. Ensuite, une fois tous enregistrés, la méthode boot de chacun est appelée. Ainsi, au moment où boot s’exécute, tous les bindings du conteneur sont enregistrés et disponibles.
Enregistrez vos service providers personnels ou tiers dans
bootstrap/providers.php.Routage
Une fois l’application démarrée et tous les service providers enregistrés, laRequest est passée au routeur pour dispatch. Le routeur dispatche la requête vers une route ou un contrôleur, et exécute aussi les middlewares propres à la route.
Les middlewares offrent un moyen pratique de filtrer ou d’inspecter les requêtes HTTP entrantes. Par exemple, un middleware inclus vérifie si l’utilisateur est authentifié ; sinon, il redirige vers l’écran de connexion. S’il est authentifié, la requête est autorisée à poursuivre.
Une fois passée tous les middlewares assignés à la route correspondante, la route ou la méthode de contrôleur est exécutée et retourne une réponse.
Retour de la réponse
Quand la route ou la méthode retourne une réponse, celle-ci remonte à travers les middlewares de la route, ce qui permet à ces derniers de la modifier ou de l’inspecter. Enfin, une fois la réponse sortie de tous les middlewares, la méthodehandle du kernel HTTP renvoie l’objet réponse à handleRequest de l’instance de l’application, qui appelle la méthode send de la réponse. send envoie le contenu au navigateur de l’utilisateur. Le cycle de vie d’une requête Laravel se termine ainsi.
Cycle de vie d’une commande Console
Vue d’ensemble
Point d’entrée artisan
Le point d’entrée des commandes console est le fichierartisan à la racine du projet. Comme pour HTTP, l’autoloader Composer est chargé et l’instance de l’application Laravel est créée.
Ensuite, le traitement est délégué au kernel Console via la méthode handleCommand de l’instance d’application.
Kernel Console et exécution de la commande
Le kernel Console, comme le kernel HTTP, charge les service providers. Après leur enregistrement et démarrage, les commandes du répertoireapp/Console/Commands sont chargées et la commande spécifiée est exécutée.
- Le fichier
artisancharge l’autoloader Composer - L’instance d’application est créée depuis
bootstrap/app.php - Le kernel Console charge les service providers
- La commande
make:controllerest recherchée et exécutée - Un code de sortie est retourné
Se concentrer sur les service providers
Les service providers sont vraiment la clé de l’initialisation d’une application Laravel. Instance d’application créée, service providers enregistrés, requête transmise à l’application démarrée. C’est tout. Comprendre en profondeur comment votre application se construit et démarre via les service providers a beaucoup de valeur. Vos service providers utilisateur sont stockés dansapp/Providers.
Le
AppServiceProvider par défaut est presque vide. C’est l’endroit idéal pour ajouter vos initialisations et bindings de conteneur. Dans les grandes applications, il est recommandé de créer plusieurs service providers spécialisés pour organiser l’initialisation par service.Différence entre register et boot
Un service provider possède deux méthodes principales.| Méthode | Moment | Rôle |
|---|---|---|
register | Appelée pour tous les providers après leur instanciation | Enregistrer uniquement des bindings dans le conteneur |
boot | Appelée après que tous les register ont été exécutés | Enregistrer view composers, listeners d’événements, autres initialisations |
Prochaines étapes
Conteneur de services
Comprenez l’injection de dépendances et le fonctionnement du conteneur de services.
Service providers
Apprenez à initialiser votre application à l’aide des service providers.