Nous avons appris à limiter nos efforts sur la couche d'accès aux données avec JPA, nous allons maintenant découvrir comment alléger notre charge de travail sur les couches vue et contrôleur grâce aux frameworks MVC ! Au programme de ce chapitre d'introduction, des rappels sur le pattern MVC, des généralités sur le concept de framework et sur son intérêt, et le point sur le marché actuel des solutions existantes.
Généralités
Rappel concernant MVC
Revenons l'espace d'un court instant sur les objectifs du pattern MVC. Il s'agit, comme vous le savez tous maintenant, d'un modèle de conception, une bonne pratique qui décrit comment le code d'une application doit être organisé. Dans une application Java EE, il découpe littéralement le code en plusieurs couches, chacune étant chargée d'assurer des tâches bien définies : nous n'allons pas disserter davantage sur ce sujet, nous avons mis tout cela en pratique depuis le début du cours et vous connaissez déjà tous les composants constituant le modèle, le contrôleur et la vue.
Les principaux avantages d'un tel pattern sont évidents :
- la clarté introduite par un découpage clair et surtout standard des différentes sections d'une application permet une maintenance du code bien plus aisée que si le code ne respectait aucune règle préétablie. C'est cette quasi-universalité du mode de développement qui confère à MVC son intérêt le plus conséquent ;
- le découpage, et donc l'isolement des différentes tâches au sein d'une application, permet une meilleure répartition du travail entre les différents profils de développeurs. Le cas le plus souvent mis en avant est celui du designer web, qui peut ainsi ne s'occuper que de la vue sans avoir à se soucier de ce qui se passe derrière, ni même de comment cela se passe.
À ces avantages s'oppose toutefois un inconvénient majeur : puisqu'il y a nécessité de délimiter clairement les couches d'une application, il faut fatalement écrire davantage de code, et la structure ainsi définie impose des répétitions de code fréquentes. Est-il besoin de le préciser ? Qui dit plus de code, dit développement plus lent, risque d'erreurs plus grand, etc.
Qu'est-ce qu'un framework MVC ?
Comme vous le savez tous, la brique de base de la plate-forme Java EE est la servlet. Tout passe par elle, et même nos pages JSP sont transformées en servlets derrière les rideaux. Eh bien un framework MVC n'est rien d'autre qu'une surcouche à cette technologie de base. En masquant ces rouages les plus basiques, une telle solution facilite le découpage et la gestion du code d'une application. Elle intervient sur le cycle de vie d'une requête dans l'application, et prend en quelque sorte la main sur son cheminement. Voilà pourquoi on qualifie souvent les frameworks MVC de frameworks d'inversion de contrôle, parfois abrégé en IoC.
À quels besoins répond-il ?
Nous avons d'ores et déjà répondu à cette question en listant les avantages et inconvénients principaux du pattern MVC. L'objectif premier d'un framework MVC est de simplifier le flot d'exécution (ou workflow) d'une application, c'est-à-dire de :
- limiter les répétitions de code impliquées par la mise en place d'un découpage du code ;
- réaliser une partie du travail redondant à la place du développeur, en effectuant des tâches génériques derrière les rideaux, de manière transparente ;
- contraindre le développeur à respecter une organisation clairement définie. Alors qu'il reste libre d'implémenter comme bon lui semble le pattern MVC lorsqu'il travaille à la main, il doit se conformer à un format plus ou moins strict lorsqu'il fait usage d'un framework ;
- par corollaire du premier point, rendre le développement de certains aspects plus rapide, permettant ainsi au développeur de se concentrer sur le cœur de l'application.
Quand utiliser un framework MVC, et quand s'en passer ?
Avant de nous pencher sur les différents types de frameworks MVC existants, réfléchissons à la question suivante : qu'est-ce qui justifie l'utilisation d'un framework MVC dans une application ? Nous venons certes de découvrir les besoins auxquels il répond, mais ce n'est pas pour autant qu'il est toujours judicieux d'en utiliser un. Ainsi, même si l'intuition nous incite à considérer qu'un framework ne peut apporter que du bon dans un projet, voici les principaux axes de réflexion à explorer :
- l'envergure du projet : si l'application développée est relativement petite, il n'est probablement pas nécessaire de mettre en place un framework, et le développement MVC "à la main" peut convenir ;
- le temps d'apprentissage : si vous ou votre équipe n'avez que peu de connaissances sur un framework MVC, alors il faut peser le pour et le contre entre le temps gagné durant le développement grâce à son utilisation, et le temps perdu en amont pour apprendre et assimiler la technologie ;
- le contexte du projet : si des contraintes sont formulées au niveau du serveur et des composants utilisables par un projet, et éventuellement au niveau des performances ou du niveau de scalabilité attendus, alors il faut déterminer si l'utilisation d'un framework rentre dans ce cadre ou non, et vérifier qu'il respecte bien les contraintes énoncées.
Framework MVC basé sur les requêtes
Définition
La première grande catégorie de frameworks MVC qualifie ceux qui se basent sur les requêtes ; on parle également de frameworks basés sur les actions.
C'est le type de frameworks MVC le plus simple à comprendre et à assimiler par les développeurs qui ont déjà de l'expérience avec le développement Java EE en suivant MVC, car il reprend dans les grandes lignes sensiblement les mêmes principes. Ce sont des solutions qui interviennent directement sur le cycle de vie d'une requête au sein de l'application (on rejoint ici cette histoire de "prise de contrôle").
Il serait nécessaire de nous y attarder plus longuement si nous n'avions jamais touché à MVC, mais puisque nous en avons fait le fer de lance de notre parcours, nous savons déjà très bien de quoi il est question ici !
Principe
Là encore, le principe est extrêmement simple à comprendre pour quiconque a déjà travaillé avec MVC. Il s'agit d'un framework web qui prend en entrée une requête issue d'un client, qui détermine ce que le serveur doit en faire et qui renvoie enfin au client une réponse en conséquence. Le flot d'exécution peut donc être qualifié de linéaire, et reprend ce que nous avons jusqu'à présent mis en place à la main dans nos exemples.
Ainsi, le développeur doit penser en termes d'actions, et associe naturellement ce que demande l'utilisateur (sa requête) à ce que l'utilisateur reçoit (la réponse). Concrètement, le développeur écrit des classes qui représentent des actions effectuées par l'utilisateur, comme par exemple "Passer une commande" ou "Voir les détails du client". Ces classes sont chargées de récupérer les données transmises via la requête HTTP, et de travailler dessus.
En somme, avec un tel framework le développeur travaille toujours de près ou de loin sur la paire requête/réponse, comme nous l'avons fait jusqu'à présent. Le gros changement à noter, mais nous y reviendrons plus tard, est la mise en place d'une servlet unique jouant le rôle d'aiguilleur géant (ou Front Controller). Celle-ci se charge de déléguer les actions et traitements au modèle métier en se basant sur l'URL de la requête et sur ses paramètres. Le développeur peut alors travailler directement sur les objets HttpServletRequest et HttpServletResponse bruts dans le modèle, ou bien utiliser le système de mapping fourni par le framework. Ce système permet au développeur de confier au framework les tâches de regroupement, conversion et validation des paramètres de requête, et si nécessaire de mise à jour des valeurs du modèle de données, avant d'invoquer les actions métier. Enfin, il doit toujours écrire lui-même les pages - bien souvent des pages JSP - en charge de créer les réponses à renvoyer au client, et il jouit donc d'une liberté totale sur le rendu HTML/CSS/JS de chaque vue.
Solutions existantes
Trois grands acteurs se partagent le devant de la scène :
- Spring, solution très répandue dont le spectre s'étend de la simple gestion des requêtes à l'ensemble du cycle de vie de l'application, bien souvent couplée à Hibernate pour la persistance des données ;
- Struts, solution éditée par Apache dont la gloire appartient au passé. Le framework a changé du tout au tout avec la sortie d'une seconde mouture qui se nomme Struts 2, mais qui à part son titre n'a rien de similaire à Struts, premier du nom. Par ailleurs, la communauté maintenant le projet semble moins active que les concurrentes ;
- Stripes, un challenger intéressant et montant, très léger et réputé pour être facile à prendre en main.
Framework MVC basé sur les composants
Définition
La seconde grande catégorie de frameworks MVC qualifie ceux qui se basent non pas sur les requêtes, mais sur les composants.
À la différence de ceux basés sur les requêtes, les frameworks basés sur les composants découpent logiquement le code en "composants", masquant ainsi le chemin d'une requête au sein de l'application. Ils essaient en quelque sorte d'abstraire les concepts de requête et réponse, et de traiter une application comme une simple collection de composants qui présentent leur propre méthode de rendu et des actions pour effectuer des tâches.
Les ressources traitant de ce sujet dans la langue de Molière sont sur la toile étonnamment légères. Si vous êtes anglophones, vous trouverez cependant de quoi faire, de nombreuses discussions intéressantes et fournies étant disponibles dans la langue de Shakespeare. Pour information, sachez qu'on parle en anglais d'action-based frameworks et de component-based frameworks.
À l'origine, de telles solutions ont été développées pour faciliter aux développeurs Java, peu familiers avec le développement web et plus proches du développement d'applications de bureau traditionnelles, la création d'applications web, sans devoir connaître les rouages de l'API Servlet. En outre, de telles solutions ont pour objectif secondaire de rendre la maîtrise des technologies de présentation web habituellement requises superflues, notamment HTML, CSS et JS.
Principe
Dans le MVC basé sur les composants, une unique servlet jouant le rôle de Front Controller va elle-même regrouper, convertir et valider les paramètres de requête, et mettre à jour les valeurs du modèle. Le développeur n'a ainsi à se soucier que des actions métier. La façon dont le contrôleur regroupe/convertit/valide/met à jour les valeurs est définie dans un unique endroit, la vue. Puisque c'est impossible à réaliser à l'aide de simple HTML "pur", un langage similaire spécifique est requis pour y parvenir. Dans le cas de JSF, c'est un langage basé sur du XML (XHTML). Vous utilisez du XML pour définir les composants de l'interface utilisateur, qui eux contiennent des informations sur la manière dont le contrôleur doit regrouper/convertir/valider/mettre à jour les valeurs et générer lui-même le rendu HTML.
Les avantages et inconvénients doivent maintenant être clairs pour vous :
- avec un framework MVC basé sur les requêtes vous devez écrire plus de code vous-mêmes pour parvenir à vos fins. Cependant, vous avez un meilleur contrôle sur le processus, c'est-à-dire sur le cheminement d'une requête au sein de l'application, et sur le rendu HTML/CSS/JS ;
- avec un framework MVC basé sur les composants, vous n'avez pas besoin d'écrire autant de code vous-mêmes. Cependant, vous avez moins de possibilités de contrôle sur le processus et le rendu HTML/CSS/JS.
Donc, si vous souhaitez réaliser des choses qui s'écartent un peu de ce que décrit le standard, vous perdrez beaucoup plus de temps si vous utilisez un framework MVC basé sur les composants.
Solutions existantes
Une fois de plus, trois grands acteurs se partagent le devant de la scène :
- JSF, ou "Java Server Faces" : il s'agit de la solution standard intégrée à Java EE 6, et les trois prochains chapitres du cours lui sont dédiés ;
- Wicket : solution éditée par Apache, elle est très en vogue grâce à sa relative simplicité. La communauté en charge de sa maintenance est très active ;
- Tapestry : solution éditée par Apache, ayant connu une évolution assez chaotique. Durant les premières années de son existence, chaque nouvelle version du framework cassait la compatibilité avec les versions précédentes, forçant les développeurs qui l'utilisent à migrer et/ou réécrire le code de leurs applications pour rester à jour… A priori cette sombre époque est maintenant révolue, et la version actuelle a été construite pour être évolutive.
Les "dissidents"
Sachez pour conclure qu'il existe plusieurs solutions déjà très populaires qui ne se classent dans aucune de ces deux catégories, mais qui sont tout de même utilisées pour développer des applications web, et qui peuvent être utilisées en suivant le pattern MVC. On retiendra notamment :
- GWT, solution éditée par Google pour la création d'applications web de type client-serveur ;
- Play!, un framework plus global qui se place au même niveau que Java EE lui-même, et qui permet de développer avec les langages Java ou Scala.
- Un framework MVC est destiné à simplifier et accélérer le développement d'une application web, et à isoler clairement le travail à effectuer par les différents profils de développeurs.
- Utiliser un framework n'est pas toujours la solution optimale, il est parfois judicieux, voire nécessaire, de s'en passer.
- Un framework MVC basé sur les requêtes (ou sur les actions) reprend l'organisation et les principes de ce que nous avons développé à la main jusqu'à présent. Il simplifie l'aspect contrôleur via l'intervention d'une servlet unique jouant le rôle d'aiguilleur géant. La vue est la plupart du temps réalisée avec la technologie JSP.
- Un framework MVC basé sur les composants masque les échanges de requêtes et réponses derrière des composants autonomes, symbolisés par l'intermédiaire de balises dans la vue. Une servlet unique joue le rôle d'aiguilleur géant.
- Le standard adopté par Java EE 6 est un framework MVC basé sur les composants : la solution se nomme JSF, ou Java Server Faces.
- D'autres modes de développement web existent sur la plate-forme Java, et sont activement développés par de grands acteurs du web et de l'Internet.