Persistance des données avec Spring Data JPA

Le dépôt en mémoire de la leçon précédente a rendu un service : il a permis de concevoir l'API sans que la base de données ne dicte la forme des réponses. Il faut maintenant le remplacer par du stockage réel, et c'est là que la plupart des projets Spring contractent leurs dettes durables.

La difficulté n'est pas d'écrire une entité — quatre annotations suffisent — mais de comprendre qu'un ORM place un intermédiaire entre votre code et le SQL réellement exécuté. Cet intermédiaire a des règles : il suit des objets dans un contexte de persistance, il décide seul du moment où il écrit, il charge ou ne charge pas les relations selon des réglages implicites, et il n'exécute une transaction que si l'appel est passé par le bon chemin. Un développeur qui ignore ces règles écrit du code qui semble fonctionner et qui produit trois cents requêtes SQL par appel, ou qui ne persiste rien du tout sans lever la moindre erreur.

Cette leçon met en place la persistance de biblio-api — les entités Livre, Auteur et Emprunt — en nommant chaque piège au moment où il se présente : le chargement EAGER qu'on croit pratique, l'equals qui casse les collections, le @Transactional qui ne s'applique pas.