Introduction à JPA et Hibernate

Une base de données relationnelle raisonne en lignes, en colonnes et en clés étrangères. Un programme Java raisonne en objets, en références et en héritage. Ces deux modèles ne se recouvrent pas : une référence Java est un pointeur en mémoire, une clé étrangère est une valeur recopiée ; un objet Java peut hériter, une table ne peut pas. Cet écart porte un nom, object-relational impedance mismatch, et tout le travail que vous faisiez à la main avec JDBC — recopier des colonnes dans des champs, retrouver un objet déjà chargé pour ne pas le dupliquer, décider quand écrire — consiste à le combler.

JPA est la réponse normalisée de la plateforme Jakarta EE à ce problème. Hibernate en est l'implémentation la plus répandue, et de loin la plus ancienne : Hibernate existait avant JPA, et JPA a été largement dessiné à partir de lui. Le résultat, pour vous, c'est un ORM qui vous laisse écrire commande.getClient().getNom() au lieu d'une jointure, et qui décide seul du moment où le UPDATE part vers PostgreSQL.

C'est précisément cette délégation qui rend le sujet difficile. Un ORM ne supprime pas le SQL, il le produit à votre place. Le jour où une page qui affichait cinquante commandes émet cinquante et une requêtes au lieu de deux, le problème n'est pas dans votre code : il est dans une décision qu'Hibernate a prise, à partir d'annotations que vous avez écrites sans en mesurer l'effet. Ce cours est construit autour de ce scénario, appelé problème des N+1 requêtes. Il apparaît dès cette leçon, il se produit sous vos yeux dans la leçon sur les relations, et il est résolu proprement dans la leçon d'optimisation.