Dans le cadre d’une veille stratégique pour un de nos clients publics, nous avons étudié le sujet des frameworks PHP. Il s’agit de faire des préconisations pour aider à l’industrialisation de la filière de développement. L’article suivant constitue la 1ère partie de la série sur les généralités.
1. Enjeux
Les frameworks PHP répondent à trois types d’enjeux :
L’accélération du processus de développement en réutilisant du code éprouvé par des projets similaires ce qui permet de faire des économies significatives en temps et en effort. Le développeur se concentre sur le développement de l’application en soi au lieu de reconstruire les fondations.
La stabilité et la sécurité sont une autre raison en faveur des frameworks. Ils limitent généralement les failles de sécurité et optimisent le code par rapport à un développement sans framework.
La diversité des frameworks et le dynamisme de leurs communautés de développement respectives, signifient qu’il y a de grandes chances d’en trouver un qui correspond aux besoins.
Les frameworks sont particulièrement adaptés dans le cadre de projets d’envergure ou contraints par le temps.
2. Couverture fonctionnelle
Nous allons étudier par la suite les fonctionnalités d’un framework PHP complet qui seront celles présentes dans la comparaison des frameworks retenus.
2.1. Affichage et moteur de template
Un framework PHP gère la « Vue » de manière classique avec un ensemble de feuilles de style, de scripts, d’images et de templates. Dans l’architecture MVC, les templates sont composés seulement de variables et d’expressions. Celles-ci sont remplacées par des vraies valeurs au moment où elles sont traitées par le « Modèle ».
Un moteur de template sert à générer n’importe quel type de contenu (HTML, XML, CSV, Latex…) plus facilement et rapidement avec un code plus lisible et concis notamment à l’aide de tags spécifiques. La maîtrise de la syntaxe du moteur de template choisi est nécessaire.
Un framework PHP n’oblige pas à utiliser un moteur de template PHP pour concevoir le rendu des pages Web. Il est possible d’utiliser directement le moteur de rendu PHP. Certains frameworks n’ont justement pas de moteur de template par défaut et préfèrent ajouter des possibilités au PHP pour faire des modèles de pages tout aussi riches.
Nous avons retenu par la suite les frameworks PHP qui peuvent s’intégrer avec le moteur Smarty. Cela permettra éventuellement à l’Administration de réutiliser les templates déjà développés ou au moins de ne pas devoir réapprendre une nouvelle syntaxe. Il est important de noter qu’aucun des frameworks étudiés n’intègre Smarty par défaut.Twig est un moteur de template alternatif qui est devenu populaire via Symfony. Il dispose d’une syntaxe relativement claire et est un composant indépendant qui peut être utilisé avec n’importe quel framework.
2.2. Routage et contrôleur
Le routage et le contrôleur sont au cœur des frameworks PHP MVC par rapport aux moteurs de templates. Le routeur permet de créer une arborescence d’URLs qui correspond à plusieurs actions et données de l’application Web. Le contrôleur est en charge de recueillir la requête du routeur, de la traiter et délivrer une réponse qui peut être une page Web, un document, une erreur, une image, etc.
Le rôle du framework est donc d’accélérer le développement des processus de traitement des requêtes par des méthodes ou des services en lien avec les données existantes. Chaque composant du framework gère généralement l’interface avec un type d’objet ou d’échange différent. Il s’agit généralement de bases de données, de flux de donnée ou de fichiers.
Illustration 3.1: Fonctionnement du framework Symfony
2.3. Validation et formulaires
Il s’agit de recueillir les entrées des utilisateurs à travers plusieurs types de champs (bouton, texte, nombre, date, téléversement, etc) qui satisfont des contraintes spécifiques tout en assurant la sécurité et l’intégrité du système. Si Smartbok peut satisfaire es besoins spécifiques de l’Administration, le choix d’un framework PHP permet d’avoir une approche plus globale pour contrôler un formulaire et empêcher l’injection de code malveillant dans les applications PHP développés.
2.4. Sécurité
Un framework intègre généralement par défaut :
l’authentification des utilisateurs et la gestion des sessions
l’autorisation, les contrôles d’accès et les rôles
la protection contre les failles de sécurité comme le cross-site scripting (XSS), le Cross-Site Request Forgery (CSRF), l’injection SQL, le contournement d’authentifications…
les méthodes de cryptage
2.5. Bases de données et ORM
Il est possible de faire beaucoup de choses avec les bases de données avec les frameworks :
exécuter des commandes SQL brutes (créer, lire, modifier, modifier)
passer par un générateur de requêtes via PDO qui permet d’accéder aux bases de données du marché en chargeant le bon pilote et protège des attaques d’injections SQL
alimenter avec des données aléatoires les bases de données pour faire des tests
générer automatiquement le schéma de base de données en ligne de commande etfaire de la gestion de version sur des bases de données (migrations)53
générer partiellement des entités à partir d’une base de données existante (reverse engineering)54
Les deux dernières fonctioonnalités nécessitent de recourir à l’’Object Relational Mapping (ORM) qui rajoute une couche d’abstraction supplémentaire en faisant la correspondance entre les bases de données et les objets. Ainsi au lieu de sélectionner les tableaux et extraire les cellules, le développeur se contente de faire une simple recherche d’objet.. L’usage de l’ORM est optionnel au sein d’un framework et seulement recommandé dans le cas d’applications complexes et réalisant un nombre de requêtes important55.
2.6. Conteneur de service
Les applications PHP complexes sont organisés en une multitude d’objets qui traitent des micro-tâches différents. Le conteneur de service permet de gérer de manière centralisée et standardisée les différents objets d’une application. En implémentant le principe d’inversion de contrôle, les dépendances entre les composants logiciels ne sont plus exprimées dans le code statique mais déterminé dynamiquement à l’exécution. L’injection de dépendance permet ainsi à de créer des services qui peuvent être appelés par les autres composants de l’application.
Le conteneur de service facilite ainsi le développement et l’usage, rend l’application plus rapide et contribue à la réutilisation et au découplage du code. Nous constatons bien que la tendance est à la généralisation de l’architecture orientée service dans les frameworks PHP dans le but de gagner en performance et en extensibilité.
2.7. Autres fonctionnalités et extensibilité
Les frameworks PHP peuvent enfin intégrer d’autres fonctionnalités orientées utilisateurs comme l’envoi d’e-mail ou le traitement de documents. L’émergence du gestionnaire de dépendance Composer56 cité précédemment dans quasiment la plupart des frameworks permet d’intégrer plus facilement de nouveaux composants..
2.8. Middleware et PSR-7
Le PSR-7 est une nouvelle norme pour le « HTTP message interfaces » soit une façon commune pour concevoir les messages HTTP. Il s’agit d’une grande avancée vers une meilleure standardisation et interopérabilité des librairies et bibliothèques PHP. Cela s’applique plus particulièrement pour les middlewares qui sont les bibliothèques qui s’intègrent entre une requête et une réponse HTTP). Dans le futur, un middleware qui sera écrit autour de ces nouvelles interfaces PSR-7 pourra être utilisé dans n’importe quel framework. En d’autres termes il sera possible de développer des composants génériques et réutilisables, c’est à dire des middlewares, qui pourront être consommée par n’importe quel framework PHP. Les frameworks importants comme Symfony, Laravel et Zend Expressive gèrent aujourd’hui le PSR-7. C’ est un signe très positif de la maturité de la communauté des développeurs PHP et de sa volonté d’aller vers une démarche plus collaborative et coopérative entre projets.
