12. Conclusion
Ce document a présenté la construction d'une application web MVC avec le framework [Spring MVC] et [Spring Boot] : une application dont les pages HTML sont fabriquées par le serveur, avec des vues [Thymeleaf], sans framework [JavaScript] côté navigateur. Il a suivi pas à pas la progression du cours [ASP.NET Core MVC], lui-même issu des cours [NestJS] et Introduction à ASP.NET MVC par l'exemple : des contrôleurs et du routage vers les vues, les formulaires, l'internationalisation, la sécurité et l'accès aux données, puis une étude de cas complète.
Les mêmes 28 exemples et la même application ont ainsi été écrits avec trois frameworks, en [TypeScript], en [C#] et en [Java]. Les notions sont les mêmes ; seuls les noms et les mécanismes changent. Les correspondances entre [ASP.NET Core MVC] et [Spring MVC] :
ASP.NET Core MVC | Spring MVC (Spring Boot 4) |
[Program.cs] (services et middlewares) | classe [@SpringBootApplication], classes [@Configuration] et méthodes [@Bean] |
fichier projet [.csproj], paquets [NuGet] | fichier [pom.xml], starters [Maven] |
[appsettings.json], [IConfiguration], options | [application.properties], [@Value], records [@ConfigurationProperties] |
injection de dépendances : [AddSingleton], [AddScoped], [AddTransient] | beans [@Service], [@Component], [@Bean], singletons par défaut |
[Controller], [[HttpGet]], [[HttpPost]], [IActionResult] | [@Controller], [@GetMapping], [@PostMapping], nom de vue ou [redirect:...] |
liaison de modèle, [[Required]], [[Range]]... | liaison de modèle, [@NotBlank], [@Min], [@Max]... ([Bean Validation]) |
[ModelState.IsValid] et réaffichage du formulaire | [@Valid], [BindingResult] et réaffichage du formulaire |
vues [Razor] ([.cshtml]), [_Layout.cshtml], [_ViewStart.cshtml] | vues [Thymeleaf] ([.html]), gabarit par [th:replace] |
vues partielles, Tag Helpers, classe mère des vues | fragments ([th:fragment]), [@ControllerAdvice] et [@ModelAttribute] |
[TempData] (dans un cookie chiffré) | attributs flash ([RedirectAttributes]), dans la session ou un cookie |
middlewares, filtres d'action et d'exception | filtres de servlet, intercepteurs, [@ControllerAdvice], [ErrorController] |
[JwtBearer], [[Authorize(Roles = ...)]] | [Spring Security] : [SecurityFilterChain], serveur de ressources, [@PreAuthorize] |
dictionnaires JSON, [@T(...)], [UseRequestLocalization] | dictionnaires JSON lus par un [MessageSource], [#{...}], [LocaleResolver] |
[Entity Framework Core], [DbContext], [LINQ] | [Spring Data JPA] et [Hibernate], interfaces [JpaRepository], requêtes dérivées, [JPQL] |
[BeginTransactionAsync], [CommitAsync] | [@Transactional], [TransactionTemplate] |
[[ConcurrencyCheck]] et version augmentée à la main | [@Version], géré par [Hibernate] |
[dotnet run], [dotnet watch] | [mvnw spring-boot:run], [Spring Boot DevTools] |
Par rapport à [ASP.NET Core], on retiendra surtout :
- [Spring Boot] configure l'application d'après les bibliothèques présentes : ajouter un starter suffit à obtenir un serveur web, un moteur de vues, une source de données ou une chaîne de filtres de sécurité, que l'on règle ensuite par des propriétés ou en déclarant ses propres beans. C'est très efficace, à condition de savoir ce que [Spring Boot] a fait à notre place : le journal de démarrage, et le niveau [DEBUG], aident à le découvrir ;
- beaucoup de comportements reposent sur des proxys : [@Transactional] ou [@PreAuthorize] n'agissent que lorsqu'une méthode est appelée depuis un autre bean. Il faut le savoir pour ne pas être surpris ;
- [Spring Data JPA] réduit la couche DAO à des déclarations : une interface, des noms de méthodes qui décrivent les requêtes, et, si nécessaire, des requêtes [JPQL]. Le verrou optimiste ([@Version]) et la traduction des erreurs de la base en exceptions de [Spring] sont fournis ;
- [Spring Security] est plus bavard que les attributs [[Authorize]] d'[ASP.NET Core], mais tout y est réglable, en [Java], au même endroit : règles d'accès aux URL, lecture du jeton, redirections, déconnexion, protection [CSRF] ;
- les vues [Thymeleaf] sont des pages HTML valides, qu'un navigateur peut afficher telles quelles ; elles ne contiennent que des expressions, pas de code [Java], ce qui les garde simples. En contrepartie, elles ne sont pas compilées : une faute dans une expression n'apparaît qu'à l'affichage de la page, et non à la compilation comme avec [Razor].
L'étude de cas montre qu'une application HTML classique, sans [JavaScript] indispensable, reste une solution simple et robuste : chaque page est une URL, le bouton « précédent » du navigateur fonctionne, et le serveur contrôle tout. Le peu de [JavaScript] utilisé (les fenêtres de confirmation) améliore le confort sans être nécessaire au fonctionnement.
Pour aller plus loin, on pourra consulter la documentation de [Spring Framework] (docs.spring.io/spring-framework/reference), celles de [Spring Boot] (docs.spring.io/spring-boot), de [Spring Security] (docs.spring.io/spring-security/reference) et de [Spring Data JPA] (docs.spring.io/spring-data/jpa/reference), le site de [Thymeleaf] (thymeleaf.org), et comparer cette application à ses sœurs [ASP.NET Core MVC] et [NestJS].