Prisma, Eloquent, Doctrine: pourquoi utiliser un ORM ?
En tant que développeurs travaillant sur le backend, nous avons un problème. Dans le monde de la programmation, on modélise par défaut la réalité avec la programmation orientée objet.
Par contre, en base de données, on modélise les données avec des tables. Ces deux éléments, les objets et les lignes de tableau, ne sont pas directement compatibles, en termes de modèle mental. Il y a un écart.
Et c'est là qu’interviennent les ORM comme Prisma, Doctrine, Active Record ou Eloquent de Laravel. Ils aident à combler ce fossé entre deux modèles mentaux, entre les données tabulaires et la programmation orientée objet.
Les ORM font le lient entre les objets et les bases de données. D'où leur nom : ORM signifie Object-Relational Mapping. Autrement dit, une correspondance entre object et relationnel.
Les ORM rendent la vie tellement plus facile. Mais ce n’est pas sans inconvénients. On y reviendra plus tard. D’abord, quels sont les principaux avantages des ORM ?
En premier lieu, les ORM permettent d'interagir avec les bases de données en utilisant une syntaxe qui vous est familière. Ca facilite beaucoup le développement.
Cette conversion fait abstraction des subtilités de la base de données et, ce faisant, fournit le deuxième avantage : elle supprime toute une série de code répétitif, du “boilerplate”, comme on dit en anglais.
Ce qui nous amène au troisième avantage : Moins de code signifie moins de maintenance et moins de bugs. Le code est plus facile à lire. Ca fait une meilleure expérience développeur. Moins de code facilite la vie à tout le monde.
Quatrièmement, dans certains cas (comme Prisma), un ORM peut vous permettre d'avoir une interface partagée qui fait abstraction des détails de la base de données sous-jacente. Vous lui dites ce que vous voulez récupérer, et lui se préoccupe de savoir comment l'obtenir.
Cependant... ce niveau d'abstraction, d'indirection, a un coût. Je compte 5 points auxquels il faut faire attention.
Premièrement, les ORM peuvent introduire une surcharge de performance car ils doivent traduire entre la base de données et le langage de programmation.
Deuxièmement, les ORM peuvent cacher des détails importants sur la base de données sous-jacente, ce qui peut entraîner un comportement inattendu ou des problèmes de performances. Si vous ne savez pas exactement ce que fait l'ORM, il est difficile d'optimiser la façon dont vous l'utilisez.
Troisièmement, les ORM sont souvent moins flexibles que l'accès à la base de données sous-jacente. Cela peut également signifier que vous êtes moins en mesure d'optimiser la façon dont vous interrogez la base de données. En effet, vous n'avez pas la possibilité de spécifier précisément à quoi doit ressembler la requête générée.
Quatrièmement, les ORM introduisent des coûts de maintenance. Ils doivent être mis à jour régulièrement pour suivre les nouvelles fonctionnalités de la technologie de base de données sous-jacente.
Cinquièmement, les ORM sont une source de complexité pour une application. Ils nécessitent une compréhension approfondie du comportement et des limites de l'ORM. Cela peut en fait rendre l'application plus difficile à déboguer et à optimiser.
Il est essentiel d'examiner attentivement les exigences spécifiques d'un projet avant de décider d'utiliser un ORM, et d'être conscient des limitations et des compromis potentiels.
Mais qu'est-ce que cela signifie ? Faut-il fuir les ORM pour autant ?
Non. Malgré tous ces écueils, les ORM restent des outils précieux pour de nombreuses applications et peuvent simplifier considérablement le processus de développement. Dans la plupart des cas, l'ORM est votre ami.
Cependant... il est important de comprendre quels sont ces inconvénients. Pour tirer le meilleur parti de votre ORM, vous devez comprendre ce qu'il fait en coulisses. Quels sont les comportements qu'il introduit. Les requêtes qu'il génère.
Comprendre le fonctionnement de votre ORM est vital pour le succès à long terme de ce que vous développez.
