Architecture MVC avec Java EE

Vous savez maintenant écrire une servlet qui traite une requête et une JSP qui affiche du HTML. Une application réelle en compte trente de chaque. La question qui se pose alors n'est plus « comment ça marche » mais « où je mets quoi » — et c'est celle qui décide si votre application sera maintenable dans deux ans.

L'expérience du terrain est sans appel. Sans discipline, la logique se répand partout : un peu de SQL dans une JSP, un calcul de remise dupliqué dans trois servlets, une règle métier écrite dans une balise de formatage. Le jour où le taux de TVA change, il faut le chercher dans quarante fichiers. Le jour où l'on veut exposer les mêmes données en JSON, il faut tout réécrire parce que la logique est indissociable du HTML.

Le patron Modèle-Vue-Contrôleur répond à cela en assignant une responsabilité unique à chaque type de composant. Ce n'est pas une bibliothèque à installer : c'est un découpage que vous imposez à votre code. En Jakarta EE, le mappage est direct — la servlet est le contrôleur, le JavaBean est le modèle, la JSP est la vue.

Ce que vous allez construire dans cette leçon, Spring MVC le fera plus tard à votre place. Le monter une fois à la main est ce qui rend Spring intelligible : quand vous verrez @GetMapping et Model, vous saurez exactement quel mécanisme est caché derrière. Un projet neuf partirait de Spring Boot ; celui qui l'utilise sans avoir jamais écrit de contrôleur frontal ne sait pas ce qu'il utilise.