Lorsqu'une équipe abandonne l'utilisation d'un mapping objet-relationnel (ORM), c'est parce qu'elle pense que les performances sont mauvaises ou qu'il y a trop de magie, alors que cela vient principalement d'une mauvaise utilisation, selon Jimmy Bogard lors d'une présentation mettant en avant ce qu'il pense être les bonnes et mauvaises manières d'utiliser un ORM avec les problèmes de mapping et de requête.
Jimmy, qui est l'auteur de AutoMapper et MVP Microsoft, décrit un ORM comme un outil pour récupérer des informations à partir d'une base de données dans une application et inversement, ce qui semble être un problème relativement simple, mais devient rapidement compliqué.
Un des problèmes du mapping que Jimmy expose est le code autogénéré créé à partir d'une base de données existante. Cela semble séduisant, mais les outils trouvent trop de relations qui vont créer des problèmes de performances. À la place, il préfère une approche centrée sur le code, ajoutant des mappings et des relations lorsqu'ils sont nécessaires, même avec une base de données existante.
D'après son expérience, une des premières choses dont les développeurs se plaignent lorsqu'ils utilisent un ORM est le lazy loading et le Select N+1, fonctionnalités qui vont ajouter une latence lorsque l'ORM récupère des données dans un modèle complexe. Le problème est que ces fonctionnalités nécessitent un nombre important d'appels en base à chaque lecture d'une propriété ou lors du parcours d'une collection. À la place, Jimmy recommande de lire toutes les données en une seule requête.
Selon lui, Repository est un anti-pattern. Dans le livre originel du DDD, les dépôts doivent être une interface qui ressemble à une collection par-dessus une base, mais il pense que le pattern est devenu une façade par-dessus un ORM qui masque de nombreuses fonctionnalités spécifiques à l'ORM. Le dépôt devient une interface passe-plat avec une implémentation qui fait juste de la délégation à l'ORM. Afin que l'ORM soit utilisé correctement, ces fonctionnalités cachées doivent être utilisées et contaminent l'application avec des détails d'implémentations transformant les dépôts en simple conteneur par-dessus l'ORM.
À la place des dépôts, Jimmy préfère modéliser chaque requête de données comme une commande en déplaçant tout le code nécessaire pour une requête dans une classe dédiée. Chaque stratégie d'accès est encapsulée dans une classe spécifique.
Une des dernières mauvaises idées est l'ignorance du SQL. ORM n'est pas une solution pour éviter de connaître le SQL, pour des systèmes critiques, il est crucial de connaître le SQL qui est exécuté et comment il s'exécute.