L'architecture de Symfony2 au crible
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 à Symfony2 : le Kernel et le Service Container.
Avant de schématiser cette architecture, nous vous proposons d'établir un bref descriptif de ces deux entités :
Le Kernel 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 Symfony2. Cependant, comprendre son fonctionnement et savoir écouter les signaux qu'il émet sont des plus indéniables 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 permettront de requêter des bases de données, d'autres, de "serializer" (linéariser) des objets. Vous aurez même le droit de créer vos propres services !
2.1 Schéma
Avant d'approfondir, découvrons au travers d'un schéma le traitement d'une requête sous Symfony2 :
Remarque :
Par souci de simplicité, le contrôleur frontal a volontairement été omis de ce schéma ; il se situe normalement entre le client et le Kernel.
Le Kernel reçoit la requête du client, il interroge le routage dans le but de savoir quel contrôleur il doit invoquer.
Une fois ce contrôleur invoqué, le Kernel attend de lui qu'il retourne une réponse HTTP, peu importe la manière dont elle est générée.
De ce fait, le contrôleur est libre d'invoquer différents services comme le modèle ou la vue, mis à sa disposition au sein du Service Container. De ces différentes interactions naît une réponse HTTP, qui est renvoyée au Kernel.
Finalement, le Kernel transmet cette réponse au client.
2.2 Le Service Container
Le Service Container contient des "services", sur le schéma précédent, on y aperçoit par exemple les services "Modèle" ou "Vue".
Remarque
Sur le schéma, nous décrivons uniquement "Modèle" et "Vue", mais il existe bien d'autres services ; certains sont présents par défaut, d'autres sont créés par le développeur.
Les services ne sont pas des concepts abstraits : chaque service est un objet PHP.
Le Service Container est la seule entité mise à disposition du contrôleur pour l'aider à générer sa requête HTTP, c'est donc un élément central de l'application.
En installant Symfony2, nous nous rendrons compte qu'il est préconfiguré avec un certain nombre de services, chacun répondant à un besoin particulier (gérer les templates, communiquer avec des bases de données, etc.).
2.3 Un framework MVC ?
Il serait réducteur de qualifier Symfony2 de framework MVC. En effet, bien que celui-ci soit configuré par défaut, nous verrons par exemple que le service Modèle n'est pas obligatoire. De plus, les services Modèle et Vue étant contenus dans le Service Container au milieu d'autres services, ils sont considérés comme des services quelconques par le framework, qui n'a en aucun cas conscience de cette architecture.
Le fait est que Symfony2 n'a pas été spécialement conçu pour accueillir ce patron de conception. Hormis la couche Contrôleur qui est obligatoire, le développeur est libre d'implémenter l'architecture de son choix pour son application.
Cependant, nous allons essentiellement travailler en MVC tout au long de cet ouvrage, car ce patron de conception répond naturellement à la plupart des besoins d'une application web moderne.
2.4 Une flexibilité à toute épreuve
Symfony2 est connu pour être un puissant framework PHP mais il est tout de même important de savoir que c'est aussi un ensemble de composants.
Chaque composant est une sorte de librairie autonome, utilisable dans n'importe quel projet PHP. En voilà quelques-uns :
Form : pour la gestion des formulaires.
Console : création de programmes en ligne de commande.
Translation : internationalisation d'applications.
Remarque
Pour un listing complet
Les composants Symfony2 peuvent être utilisés dans n'importe quel projet PHP. Le framework Symfony2 est le projet qui les exploite pleinement et de manière approfondie. Mais il en existe d'autres : Silex, par exemple, est un framework PHP ultraléger, développé entièrement autour des composants Symfony2.
Symfony2 comble certains manques de Symfony1. Dans leurs premières versions, les composants étaient très difficilement utilisables de manière autonome, notamment à cause d'un système d'autoload (autochargement des classes) peu standard et une omniprésence du patron de conception Singleton (cf. chapitre L'injection de dépendances pour plus d'informations sur ce patron).
Ces défauts ne sont plus d'actualité depuis Symfony2. En plus des traditionnelles références de sites web à fort trafic utilisant le framework, comme c'était le cas avec "Yahoo! Questions/Réponses" ou "Delicious", Symfony2 en possède désormais un autre type : les projets PHP open source ayant adopté ses composants. On citera notamment les CMS (Content Management System) Drupal ou EZ Publish.
3. Les bundles
3.1 Concept
Un "bundle" est un module compatible avec n'importe quelle application Symfony2. Il contient une multitude d'éléments comme des contrôleurs, des templates, des règles de routage ou des services.
Un bundle est une sorte de plug-in. Cependant, il est important de noter que les bundles sont les seules entités capables de modifier le comportement de votre application. La quasi-totalité de ce que vous allez développer sera contenue dans des bundles.
Remarque
Le framework Symfony2 lui-même est développé autour d'un bundle principal, dont le but est de gérer la manière dont les composants sont utilisés : le framework Bundle.
3.2 Un écosystème mature
Symfony2 possède une communauté très active et de nombreux bundles sont mis à la disposition de tous. Un site web a même été créé afin de les regrouper et de les classer par popularité : http://knpbundles.com/. Comme vous pouvez le constater, il y en a énormément, la raison est simple.
Un bundle étant compatible avec n'importe quelle application Symfony2, chaque développeur est un contributeur potentiel à l'écosystème de bundles. Pour cela, il a uniquement une décision à prendre : rendre son bundle public.
Ce n'est pas forcément aussi simple avec d'autres frameworks, où le développeur doit souvent extraire son code dans un plugin et l'adapter pour le rendre "réutilisable" ; cela nécessite un apprentissage et peu nombreux sont les développeurs à franchir le pas
Sous Symfony2, c'est moins le cas, bien qu'il y ait toujours quelques réglages à effectuer sur un bundle avant qu'il ne soit réellement réutilisable dans d'autres projets. Ces réglages sont souvent plutôt minimes.
Après avoir rodé votre bundle fétiche dans plusieurs de vos projets et vérifié sa capacité d'adaptation, peut-être envisagerez-vous de le partager sur http://knpbundles.com/ pour contribuer à cet écosystème !
Remarque
Il peut être intéressant d'utiliser des bundles open source pour gérer certaines tâches répétitives comme la gestion des utilisateurs, les commentaires, etc.
Cet article est constitué à partir de bonnes feuilles tirées de l'ouvrage "Symfony2, Développez des sites web PHP structurés et performants", de Bilal Amarni, publié aux Editions Eni.