Introduction à Spring MVC

Écrire une application web en Java sans framework est un exercice instructif, et personne ne le fait deux fois. Il faut déclarer une servlet par écran, lire les paramètres à la main dans HttpServletRequest, les convertir depuis des chaînes de caractères, vérifier qu'ils ne sont pas absents, décider quoi faire quand la conversion échoue, choisir un code de statut, puis écrire le HTML caractère par caractère dans le flux de sortie. Le code métier — les trois lignes qui comptent vraiment — se noie dans cette plomberie, et cette plomberie est réécrite à chaque écran.

Le problème n'est pas la quantité de code. C'est que ce code répétitif est du code de décision. Chaque servlet décide seule comment interpréter la requête, comment signaler une erreur, comment produire sa réponse. Au bout de trente écrans, une application contient trente conventions légèrement divergentes, et le moindre changement transversal — ajouter une trace, imposer un format de date, gérer les erreurs uniformément — devient une chasse au trésor dans trente fichiers.

Spring MVC répond à cela par un renversement : au lieu de laisser chaque écran se débrouiller, une unique servlet reçoit toutes les requêtes de l'application et orchestre leur traitement. Cette servlet ne connaît rien à votre métier ; elle sait seulement identifier le bout de code responsable d'une URL, lui fournir des paramètres déjà convertis et validés, puis transformer sa valeur de retour en réponse HTTP. Votre travail se réduit alors à écrire des méthodes Java qui reçoivent des objets et renvoient des objets.