Les tendances du marché

Depuis la sortie de la première version de PHP (qui s’appelait alors PHP/FI) en 1995, de nombreux projets gravitent autour de PHP. Le plus célèbre d’entre eux, PEAR, a pour objectif de fournir une bibliothèque structurée de code Open Source PHP, tout en facilitant sa distribution et sa maintenance, ainsi qu’un cadre pour le développement d’extensions (règles de codage, mailing lists, outils, etc.). Il s’agit d’une bibliothèque d’assez bas niveau, complétant la bibliothèque PHP de base en y ajoutant des fonctions telles que le traitement des flux XML (PEAR_XML), la manipulation des images (PEAR_Image), l’abstraction de bases de données (PEAR_DB), la gestion des requêtes HTTP (PEAR_HTTP), etc. Même si de nombreuses applications PHP (la plupart en réalité) font appel à PEAR, il est difficile de parler de véritable framework PHP.

Plusieurs projets se placent dans le sillage de PEAR, avec une volonté supplémentaire de fournir un réel cadre structurant pour le développement d’applications Web. Les deux principaux sont eZ components, de la société eZ Systems (qui édite notamment le CMS Open Source eZ Publish), et le Zend Framework, de la société Zend (qui est derrière le langage PHP). Ces deux frameworks ont vocation à permettre à une équipe de développement de développer une application complète en appelant des fonctions d’assez haut niveau (authentification et droits d’accès, moteur de workflow, moteur de recherche, etc.).

La dernière tendance, en matière de frameworks de développement Web, est aux frameworks dits "RAD", pour Rapid Application Development (développement rapide d’applications). L’initiateur de cette vague est le framework Ruby On Rails (pour le langage Ruby) dont la première version date de 2004. Les deux idées fortes de RoR sont :

• ne pas se répéter : on ne code les choses qu’une seule fois, à un seul endroit (le framework se charge de générer automatiquement tout ce qui peut l’être) ;
• convention plutôt que configuration : allègement du code et des fichiers de configuration par l’emploi de conventions simples et explicites.

Un framework RAD se compose de :

• une implémentation du motif de conception MVC (Modèle, Vue, Contrôleur)
• une gestion facilitée d’un certain nombre d’opérations courantes (création d’un modèle de données, validation de formulaires, navigation, internationalisation, etc.)
• de nombreux helpers (fonctions de haut niveau permettant de s’abstenir d’écrire de longues lignes de code) ainsi que des widgets Ajax (Asynchronous Javascript And XML) ;
• des scripts permettant d’automatiser les tâches (comme la génération d’un squelette d’application ou la création des tables en base de données) ;
• un environnement de développement intégré (IDE) ;
• une documentation exhaustive.

Les frameworks RAD se caractérisent par une prise en main extrêmement rapide et une productivité incomparable pour le développement d’applications Web de type "Web 2.0" (la création d’une application de type blog peut se faire en un quart d’heure à peine). En revanche, ils trouvent leurs limites lorsqu’il s’agit de développer des applications métier complexes interagissant fortement avec le système d’informations.

En PHP, plusieurs frameworks RAD ont vu le jour, dont les plus connus sont Seagull et surtout Symfony, développé par la société française Sensio et utilisé dans un nombre croissant de projets à travers le monde (dont la plupart des nouveaux projets de la société Yahoo !).

Exemples de projets réussis

ScreenTonic s’appuie sur le framework Seagull pour gérer ses campagnes publicitaires

ScreenTonic est une société spécialisée dans la publicité sur téléphone mobile. Elle a commencé à développer un produit de gestion de campagnes publicitaires pour téléphones mobiles en 2003. En 2005, elle a décidé de redévelopper complètement son logiciel, dans l’optique de séduire les utilisateurs grâce à un produit innovant, multi-usage et très "Web 2.0".

Le choix s’est porté sur le framework Seagull, qui était à l’époque un des seuls frameworks RAD PHP. L’attention a été portée sur les phases de conception, suivies de phases de réalisation très courtes (dans un rapport variant de 3 à 6 entre la conception et la réalisation !). Par rapport au modèle MVC classique, une couche supplémentaire de services a été intercalée entre le contrôleur et les modèles, afin de simplifier la mise en place de règles métier transverses.

La plateforme déployée (2 serveurs frontaux et 1 serveur de base de données) permet de répondre à la demande d’une centaine de clients de ScreenTonic partout dans le monde.

En 2007, ScreenTonic a été rachetée par la société Microsoft, tout en conservant son identité propre.

Refonte du site Internet d’une banque de gestion privée avec Symfony

Cette société de gestion de portefeuilles assure également la transmission des ordres pour les clients souhaitant prendre eux-mêmes leurs décisions d’investissement. Conscient de l’apport d’Internet dans le secteur de la finance, cette banque a souhaité accroître les fonctions offertes à ses clients via Internet. Cette volonté s’est traduite par la refonte complète de son site internet et par la mise à disposition de ses Partenaires d’un espace dédié, interfacé avec les outils propres au système d’information la banque.

Pour réaliser cette refonte, il a été choisi de s’appuyer sur le framework Symfony, qui, outre son intérêt purement technique, dispose d’une communauté active et d’une documentation très complète. A côté de Symfony, le projet utilise également les bibliothèques FPDF (génération de PDF) et Image Graph (création de graphes au format PNG). Par ailleurs, le site met en œuvre les dernières avancées ergonomiques réalisées pour les interfaces web, à l’aide d’Ajax.

Au niveau infrastructure, la plateforme, hébergée chez Colt, comprend un unique serveur qui permet de répondre aux 2000 à 3000 visiteurs quotidiens sur le site.

Architectures types

Le modèle MVC

Le modèle MVC (Modèle, Vue, Contrôleur) est un fondamental en conception d’applications Web, il est mis en œuvre par la plupart des frameworks RAD.

1. Le navigateur envoie une requête au serveur Web, qui la fait suivre au Dispatcher.
2. Le dispatcher analyse l’URL demandée et instancie un Contrôleur en conséquence.
3. Le contrôleur charge alors les Modèles dont il a besoin.
4. Chaque modèle, qui représente un jeu de données stockées en base, effectue les traitements nécessaires (chargement, mise à jour, contrôles, etc.).
5. Le contrôleur récupère les modèles.
6. Le contrôleur instancie la Vue correspondant à l’action demandée et lui passe les modèles en paramètre.
7. La vue génère la page ou le fragment (HTML, XML, etc.) puis le transmet au navigateur dans la réponse.

Architecture mise en place chez Richelieu Finance

Bien qu’un peu atypique, l’architecture mise en place chez Richelieu Finance reste classique pour une application PHP Symfony. Le framework gère les requêtes HTTP entrantes de la manière suivante :

1. réception de la requête par le système de routage de Symfony
2. utilisation du routage internationalisé, développé pour les besoins de Richelieu Finance
3. appel du module (contrôleur) correspondant à la requête
4. éventuel accès au modèle, possible de deux manières :
5. en employant le couple Propel/Creole, pour les données du CMS de Richelieu Finance
6. en employant les DB DataObjects de PEAR, principalement utilisé pour l’accès aux données financières
7. délégation de la réponse à la vue, par le biais du système de templates de Symfony.

Les rapports PDF, les graphiques de performance, etc., sont tous générés en employant Symfony et, au besoin, une librairie externe qui est alors chargée par le framework.

Les critères de choix

Voici les principaux critères à prendre en compte au moment de choisir un framework de développement PHP :

• Bibliothèques fournies : techniques (authentification, multi-SGBD, Web Services, tests unitaires, etc.), fonctionnelles (génération de PDF, internationalisation, gestion de contenus, etc.), Ajax (widgets, accès simplifié au DOM, ajout de composants personnalisés, etc.)
• Outillage : scaffolding, génération automatique de code, mapping SGBD, etc.
• Utilisation d’autres briques standards : PHP (PEAR, etc.), Javascript (jQuery, Prototype, etc.)
• Environnement de développement (IDE) : coloration syntaxique, auto-complétion, navigation contextuelle, accès à la documentation, débogage, etc.
• Performances : un framework RAD n’est pas destiné à augmenter les performance applicatives (l’abstraction et la séparation des couches applicatives a un coût), mais à réduire le temps de développement. Mais il ne faut pas pour autant négliger la question des performances (surtout si vous ne maîtrisez pas la plateforme d’hébergement).
• Qualité du code : la première documentation, c’est un code bien écrit ; c’est un gage de pérennité pour le framework.
• Qualité de la documentation : tutoriels, documentation technique, exemples de code, etc. La qualité de la documentation garantit l’indépendance technique, elle favorise la montée en compétence rapide sur l’outil. Par ailleurs, une documentation multilingue favorise le taux d’adoption par la communauté internationale.
• Activité de la communauté : une communauté active est signe de bonne santé, et permet en outre d’avoir accès à un support gratuit et bien souvent de qualité. Une communauté diversifiée est un gage supplémentaire de pérennité.
• Compétences disponibles : il faut prendre en compte les compétences à la fois en développement et en exploitation (cet aspect est trop souvent ignoré par les développeurs).