Dans la jungle des frameworks Web disponibles aujourd’hui il peut être difficile de s’y retrouver. Comment choisir le bon ? Celui qui va vous permettre enfin d’augmenter votre productivité dans le développement d’applications Web ?

Mais surtout, un framework Web moderne, c’est quoi ?

A la base, la technologie

Evidemment le choix de votre framework va tout d’abord dépendre de votre technologie de prédilection; RubyOnRails pour ruby, Django pour python, Grails pour groovy, Symfony pour PHP, Play! pour Java … peu importe la technologie en fait : chaque technologie propose un ou plusieurs frameworks. Si vous regardez un peu plus en détail ces différents frameworks vous remarquerez qu’au délà du langage de programmation utilisé, ils partagent les mêmes composants et les mêmes concepts fondamentaux.

Cependant le choix de la technologie n’est pas anodin. Vous devez impérativement choisir un framework qui s’appuie sur la technologie qui vous convient; celle où vous et vos équipes êtes à l’aise. Chaque technologie a sa propre philosophie; et celle-ci a forcément déteint sur la manière dont est conçue le framework. Si vous venez d’un langage statique et très structuré comme Java, vous pourriez bien vous trouver un peu perdu face à l’approche des problématiques adopté par Django par exemple… Choisir un framework qui s’appuie sur une technologie qui vous est totalement étrangère a de nombreuses conséquences, et si vous cherchiez à augmenter votre productivité vous pourriez bien au contraire vous retrouver à passer un temps précieux à faire les choses les plus simples.

Un framework impose son style d’architecture

Globalement il y a deux façons d’appréhender le développement d’applications Web.

Soit on considère que l’architecture du Web est importante. Le Web s’appuie sur le protocole HTTP qui est un protocole sans état. Rien n’existe dans HTTP au dèla du simple couple requête-réponse. On doit donc concevoir l’application Web comme un ensemble de jeux requête-réponse indépendants les uns des autres. Reste à gèrer un minimum d’état global, souvent simplement pour gérer l’authentification, et là quelques patterns simples existent qui permettent de gérer ces cas aux limites sans remettre en cause l’architecture fondamentale (utilisation de session, cookies, …).

Sinon on peut également considérer que le coté “sans état” du Web est une aberration et vouloir s’appuyer sur un framework qui le masque et utilise HTTP comme un simple protocole de communication. De nombreux frameworks proposent une implémentation basée sur cette approche; dans ce type d’applications, les composants (pages, boutons, formulaires) existent sur le serveur en dehors de toute requête HTTP. Les frameworks de type JSF en Java s’appuient sur ce principe qui a l’avantage certain de proposer aux développeurs non familiers du Web un cadre de développement rassurant en première approche: les pages sont construites en glissant-déposant des composants graphiques et en leur associant des traitements.

Cependant en reniant l’aspect sans état du Web on va généralement à la rencontre de problèmes assez complexes à gérer; gestion des boutons suivant/précédent/rafraichir des navigateurs, gestion des bookmarks, des points d’entrée dans l’application non prévus, distribution de l’application sur plusieurs serveurs, …

Le Web a une architecture, respectons la ! Les frameworks que nous avons cité plus hauts (RoR, Django, Symfony, Grails, Play!, …) s’appuient tous au maximum sur l’architecture originale du Web. Et ce n’est pas un hasard si ce sont de ces frameworks dont tout le monde parle aujourd’hui.

Les composants indispensables

Tous les frameworks cités plus haut sont ce que l’on appelle des frameworks MVC. Ils partagent tous la même architecture qui décompose l’application en 3 parties. La couche Controller qui est notifiée des évenements HTTP et qui contient la logique permettant de générer la réponse. Le couche Vue, chargée de générer la réponse proprement dite et qui s’appuie généralement sur un moteur de template. Enfin la couche Modèle qui représente les fonctionnalités de l’application, son modèle objet et ses traitements métiers.

Le “Router” connecte le Web à l’application

Quel type d’évènement HTTP est capable de recevoir l’application et comment sont-ils “traduits” par le framework ? C’est généralement ce composant (que j’appelle ici le “Router”) qui est chargé de faire ce mapping.

Un bon framework est capable de prendre en charge l’ensemble des requêtes HTTP disponibles, doit faire attention au sens du verbe HTTP utilisé dans la requête (GET, POST, …) et ne doit pas imposer de limites dans les schémas d’URL utilisés. D’une manière générale on retrouve souvent les objets requêtes et réponses au niveau du framework et ceux ci doivent se rapprocher au maximum de la logique portée par les requêtes et les réponses HTTP.

Un bon framework Web est également capable de transformer automatiquement les données transportées par la requête HTTP en objets directement exploitables par la technologie de l’application.

Le système de template

Générer les pages HTML affichées à l’utilisateur est une grosse partie du travail que doit réaliser une application Web. Un bon système de template est nécessaire pour faciliter ce rendu. Typiquement on attend d’un système de template qu’il soit capable de naviguer dans le modèle objet de l’application afin d’en extraire l’information intéressante mais aussi qu’il permette d’effectuer les opérations algorithmiques élémentaires (itérations, parties conditionnelles). On utilise alors un langage d’expression simple.

Ce langage d’expression n’est pas un langage de programmation. Même si le framework s’appuie sur une technologie à typage statique, un langage d’expression dynamique simple est généralement plus adapté au système de template. Celui-ci doit permettre d’accéder au moins en lecture aux attributs des objets, et de gérer simplement les cas de valeurs non définies.

Un bon système de template permet de créer des fonctions réutilisables sous forme de tags et des helpers permettant d’affiner l’affichage des types de bases (numérique, date, …). L’héritage entre templates est également un gros “plus” : cette technique permet de composer des pages dont certaines parties sont communes (menus, entête et pied de page, …) et de garantir ainsi une cohérence entre les pages de l’application.

Enfin la gestion de l’internationalisation est indispensable. Cela comprend d’une part la possibilité d’externaliser les messages dans des fichiers de traduction, mais également tout simplement d’être capable d’afficher tous les caractères possibles et donc de supporter entièrement UTF-8 !

L’accès aux données

Les langages que nous utilisons pour le développement d’applications Web sont majoritairement des langages orientés objet, tandis que les données sont généralement stockées dans des bases de données relationnelles. Pour résoudre ce problème historique “d’impedance mismatch”, des outils ORM (Object Relationnal Mapping) sont nécessaires.

Pour une efficacité maximum ce composant ORM doit être parfaitement intégré au framework. Les frameworks s’appuyant sur des langages dynamiques sont généralement avantagés sur ce point car ils ont la possibilité d’adapter “dynamiquement” la structure des objets en fonction du schémas de la base de données.

Mais peut importe l’outil final, tant qu’il permet de créer un vrai modèle objet. Fuyez les frameworks ringard qui vous impose de séparer structure de données et traitements. Cet anti-pattern, le bien nommé “Anemic Domain Model” touche plus particulièrement les frameworks Java influencés par une décennie de mauvaises pratiques initiées avec les EJB. N’oubliez pas que le principe même de la théorie des langages objets et de mixer données et traitement … !

Le plus important : la productivité

C’est le point essentiel. C’est même pour nous la principale raison-d’être d’un framework: augmenter la productivité des développements. La première manière d’améliorer la productivité est évidemment de fournir un cadre de développement, une architecture et des fonctions de haut niveau. Mais il y a également des points plus concrets sur lesquels un framework Web moderne se doit d’intervenir :

Une structure de projet “clé en main”

Un bon framework est capable de générer en une commande une structure de projet prête à l’emploi et prête à être exécutée. Outre le fait que le démarrage d’un nouveau projet est notablement accéléré cela a également un effet de bord intéressant: la structure même du projet est imposée encore plus drastiquement aux développeurs qui n’ont alors aucune raison de s’en écarter. Vous remarquerez que rien ne ressemble plus à un projet Ruby On Rails qu’un autre projet Ruby On Rails, alors que ce n’est pas forcément vrai entre deux projets Struts par exemple.

Le rechargement à chaud

Pour être à l’aise un développeur a besoin de voir immédiatement le résultat de ses modifications sans avoir à jouer un cycle long de compilation, déploiement, redémarrage du serveur. C’est vraiment important. Ici les frameworks qui s’appuient sur des langages de scripts sont généralement avantagés puisqu’ils ne connaissent pas de phase de compilation. Cependant il est possible d’obtenir des résultats équivalent même avec des langages compilés. Par exemple le framework Play! bien qu’utilisant Java est capable de détecter une modification du code source et de prendre en charge automatiquement les phases de compilation et le rechargement à chaud.

La qualité des rapports d’erreur

Même avec le meilleur framework et le meilleur développeur des erreurs surviennent inévitablement. Et ce n’est pas grave en soit. Ce qui est important est comment ces erreurs sont rapportées au développeur : de la qualité des informations remontées par le framework dépend la résolution rapide de l’erreur. Un bon framework Web affichera directement les erreurs dans le navigateur de manière lisible et surtout mettra directement en relation l’erreur et le code source de l’application.

Play!, notre framework de développement Web

Toutes ces techniques et beaucoup d’autres sont implémentées dans Play! notre framework de développement Web. Notre vision claire des objectifs d’un framework et notre volonté d’améliorer sans cesse notre productivité fait de Play! notre arme absolue pour le développement Web.

Si vous cherchez un très bon framework Web en Java, n’hésitez pas à le tester !

Cet article a été publié le Mercredi 11 février 2009 à 3:16 et est classé dans Frameworks. Les commentaires sont fermés, mais vous pouvez faire un trackback depuis votre propre site.