Projet complet avec Spring Boot

Les sept leçons précédentes ont traité chaque sujet isolément. Ce chapitre les assemble en une application de librairie en ligne, avec le découpage en couches, les dépôts, la pagination, la gestion des transactions et les tests. L'objectif n'est pas de montrer une architecture exemplaire : c'est de montrer où chaque piège vu précédemment se manifeste dans un projet réel, et quelle décision de conception le neutralise.

Spring Data JPA ajoute au-dessus de JPA un mécanisme qui mérite qu'on s'y arrête : il génère l'implémentation des dépôts à partir du nom des méthodes. Écrire findByAuteurNomContainingIgnoreCase suffit à obtenir la requête correspondante. C'est un gain de temps réel, et un piège tout aussi réel — parce que rien dans le nom d'une méthode ne dit quelles relations seront chargées, et qu'on retombe donc dans les N+1 sans même écrire de JPQL.

L'organisation retenue ici s'appuie sur une règle unique, qui découle de tout ce qui précède : une entité ne franchit jamais la frontière de la couche transactionnelle. Les entités vivent dans le service, les DTO en sortent. Cette règle élimine d'un coup les LazyInitializationException, les N+1 déclenchés depuis la couche web, et les fuites de données internes dans les réponses HTTP.