Ressources
Depuis le début du cours, nous avons empilé les couches d’abstraction : JDBC, puis JPA, puis Spring Data JPA. À chaque étage, nous écrivons moins de code et gagnons en confort. Mais chaque abstraction a un prix, et ce prix ne devient visible que sur des volumes de données réalistes ou sur des requêtes un peu inhabituelles.
L'idée à retenir
Un ORM n’est pas une solution universelle à l’accès aux données : c’est un outil très efficace pour manipuler un graphe d’objets métier (charger une commande, la modifier, la sauvegarder). Il devient contre-productif dès qu’on sort de ce cas d’usage.
Ce chapitre a pour but de vous donner les signaux d’alerte : savoir reconnaître le moment où l’ORM n’est plus le bon outil, et savoir quoi faire à ce moment-là.
À ne pas confondre avec le chapitre Performance
Le chapitre JPA Performance traite des cas où l’ORM est le bon outil, mais mal utilisé : un N+1, une pagination qui charge tout en mémoire, un contexte de persistance trop gros. Ces problèmes se corrigent sans quitter JPA.
Le présent chapitre traite des cas où l’ORM n’est pas le bon outil, et où la seule bonne réponse est d’en sortir.
Nous allons voir successivement :
- ce que l’ORM ne parvient pas totalement à masquer, même bien utilisé (impedance mismatch résiduel) ;
- le cas où il est structurellement le mauvais outil (reporting et requêtes analytiques) ;
- et enfin, les alternatives à utiliser en complément de JPA.