Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Symfony 6
  3. Architecture du framework
Extrait - Symfony 6 Développez des sites web PHP structurés et performants
Extraits du livre
Symfony 6 Développez des sites web PHP structurés et performants Revenir à la page d'achat du livre

Architecture du framework

Le modèle de conception MVC

1. Définitions et responsabilités

L’acronyme MVC (en anglais : Model View Controller) est un terme très répandu dans l’univers du développement logiciel. Il qualifie un modèle de conception (ou Design-Pattern en anglais), dont l’objectif est d’identifier précisément les responsabilités des différents composants d’une application afin d’augmenter sa maintenabilité et son évolutivité.

Le modèle MVC est un modèle de conception d’architecture logicielle dont les premières implémentations remontent au début des années 1980 dans le langage SmallTalk. L’objectif étant de maîtriser une certaine complexité applicative, il est décidé d’affecter des tâches précises à trois catégories de composants :

  • Le modèle : des composants responsables de la gestion des données et des traitements métier de l’application.

  • La vue : pour prendre en charge l’affichage des informations à destination de l’utilisateur final.

  • Le contrôleur : servant d’aiguilleur entre l’utilisateur, les données et la vue.

Repris à la fin des années 1990 par la plateforme Java Enterprise Edition dédiée au développement web, il a ensuite été appliqué à bien d’autres technologies de développement d’applications web et de sites web, et donc en PHP dans Symfony.

a. La vue

La vue correspond à la partie « présentation ». C’est par celle-ci que l’utilisateur interagit avec l’application.

Elle désigne souvent des templates ; un template est un « gabarit », une mise en page permettant de présenter des informations aux utilisateurs au travers d’une interface.

Dans le contexte d’une application web, un template contient essentiellement du HTML pour la mise en page, ainsi que du code spécifique, PHP ou autre, pour y intégrer...

Architecture de Symfony

1. Présentation

Nous allons maintenant découvrir les principales entités du framework participant au traitement d’une requête, et en découvrir deux qui sont spécifiques à Symfony : le Kernel et le Service Container.

Avant de schématiser cette architecture, voici un bref descriptif de ces deux entités :

  • Le Kernel (noyau, en français) est le cœur du framework. C’est un composant interne et il n’est pas obligatoire de connaître son existence pour développer sous Symfony. Cependant, comprendre son fonctionnement et savoir écouter les signaux qu’il émet est essentiel pour bénéficier pleinement des possibilités offertes par le framework.

  • Le Service Container est un composant incontournable. C’est une sorte de boîte à outils, dans laquelle vous trouverez ce qu’on appelle des « services ». Ces services sont divers et variés. Certains vous permettent de requêter des bases de données, d’autres de sérialiser des objets. Vous aurez même le droit de créer vos propres services.

2. Le contrôleur frontal

Il existe un troisième composant important : le contrôleur frontal.

Le contrôleur frontal n’est pas véritablement une spécificité de Symfony ; il correspond à une approche standard du modèle MVC qui part du principe que tout le traitement bas niveau...

Symfony Flex

1. Présentation

Symfony Flex représente l’approche pour installer des dépendances et donc des fonctionnalités supplémentaires dans un projet Symfony depuis la version 4 du framework.

Symfony Flex rend obsolète l’ancien système de « bundle », jugé finalement trop contraignant pour installer de nouvelles dépendances. Dans cet ancien système, en plus de devoir installer une nouvelle dépendance, il était souvent nécessaire d’agir manuellement sur la configuration d’un nouveau bundle ; avec Symfony Flex, tout est pris en charge.

L’idée fondamentale qui fait la différence avec les bundles, c’est que Flex ajoute une configuration par défaut immédiatement opérationnelle en plus de la dépendance, et, dans la majorité des cas, cette configuration n’a pas besoin d’être modifiée.

Toutes les tâches que Flex doit exécuter sont décrites dans un fichier au format JSON (JavaScript Object Notation) appelé Recette Flex.

2. Fonctionnement de Symfony Flex

À la base du fonctionnement de Symfony Flex, il y a l’outil Composer présenté dans le chapitre Mise en place d’un projet Symfony. Symfony Flex est en fait une extension de Composer permettant d’ajouter des traitements en plus...

Les environnements

1. Principe et apports

Un projet de site ou d’application web dispose généralement de plusieurs copies. Il est par exemple installé sur le serveur de production, sur les postes des différents développeurs y participant ou sur des serveurs de test, de préproduction, de recette, etc.

Ces différentes copies n’ont pas les mêmes attentes et il est important de pouvoir y répondre. Elles n’utilisent pas les mêmes bases de données, ne nécessitent pas le même type de débogage et possèdent potentiellement des configurations applicatives différentes. Les environnements sont une fonctionnalité majeure de Symfony. Ils permettent au projet de réagir différemment selon le « mode » sous lequel vous choisissez de l’exécuter.

Historiquement, Symfony définit les environnements prod, dev et test. Ils correspondent à des noms prédéfinis depuis Symfony2, mais aujourd’hui Symfony permet de choisir le nom souhaité pour un environnement. Le fichier .env situé à la racine du projet est la clé de ce système d’environnement et explique d’ailleurs dans ses commentaires l’ordre de chargement de fichiers d’environnement. Ce fichier contient également une variable d’environnement...

Le chargement automatique de classes

Le chargement automatique des classes (ou autoload) est un concept clé de Symfony.

L’organisation d’un projet Symfony est massivement orientée objet : hormis les contrôleurs frontaux et la console, les fichiers PHP contenant du code procédural sont quasi inexistants. En pratique, chaque fichier PHP d’un projet contient une classe et ce fichier est placé à un endroit précis, de manière à faciliter le chargement de la classe qu’il contient.

Cette organisation n’est pas spécifique à Symfony, mais à Composer. Composer est capable d’autocharger toutes vos classes, grâce à la configuration de la section autoload du fichier composer.json.

1. Le standard PSR-4

Par défaut, dans un projet Symfony, la section autoload du fichier composer.json contient la configuration suivante :

{  
   "autoload": {  
       "psr-4": { "App\\": "src/" }  
   }  
} 

Cette dernière configure un chargeur automatique de classe de type PSR-4. Le standard PSR-4 est présenté dans le chapitre Mise en place d’un projet Symfony dans la section Règles et conventions d’organisation du projet. Cette configuration...

La console

1. Présentation

La console est l’outil permettant d’interagir avec une application Symfony en ligne de commandes (CLI ou Command Line Interface).

Contrairement à l’interface web, accessible au travers du contrôleur frontal, la console est un outil du développeur et n’est en aucun cas destinée à être utilisée par les utilisateurs de l’application.

La console est située dans le dossier bin et elle correspond au fichier console. C’est un fichier PHP, la console peut donc être exécutée de cette manière (dans un interpréteur de commandes) :

php bin/console 

Exécuter le fichier tel quel ne fait qu’afficher une liste de commandes. En pratique, vous utiliserez différents arguments, dont le plus important est le nom de la commande.

Note aux utilisateurs de systèmes Unix

Ce fichier comportant un shebang, vous avez la possibilité d’utiliser le raccourci suivant :

bin/console 

Dans ce cas-là, assurez-vous d’avoir, en plus des droits de lecture, les droits d’exécution sur ce fichier.

2. Les commandes

La console est utilisée pour lancer des commandes. C’est son seul et unique usage. Chaque commande est chargée d’effectuer une tâche donnée. Ces tâches sont par exemple le vidage du cache, l’assistance au développeur en générant automatiquement certains fichiers pour lui, en mettant à jour la base de données...

Les outils pour le débogage

1. Le profiler Symfony

Le profiler de Symfony est un outil qui s’intègre à l’ensemble des pages de votre application ou site web dès lors que l’environnement est défini à dev. Le profiler se présente sous la forme d’une barre de débogage présente en bas des pages de l’application lorsque cette dernière est sollicitée dans un navigateur web.

images/03EI02N.png

Le profiler Symfony affiché sur un contrôleur nouvellement généré et indiquant la version du framework (6.4.6) à droite

Le profiler Symfony permet d’avoir un aperçu de toutes les informations relatives à la requête reçue ainsi qu’à la réponse renvoyée pour une action donnée, comme :

  • les erreurs et exceptions survenues lors de l’exécution des traitements ;

  • la structure des formulaires invoqués ;

  • les informations d’authentification (si les fonctionnalités de sécurité Symfony sont mises en œuvre) ;

  • les requêtes SQL émises vers la base de données.

Ainsi, en cliquant sur l’icône associée aux informations de base de données (entourées sur la capture d’écran ci-dessous), on peut voir les requêtes SQL émises par l’application vers la base...