Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ? Eli Bendersky donne son avis

Le , par Bill Fassinou

18PARTAGES

12  1 
Êtes-vous pour l'utilisation d'un ORM (mapping objet-relationnel) ? Pourquoi ? Partagez vos avis
L’arrivée des ORM pour les langages de programmation a apporté un certain nombre d’avantages s’agissant de la manipulation et la modification de données dans la construction d’une application. Un ORM (Object Relational Mapping) est un ensemble de librairies qui vous permettent d’interagir d’une manière plus simple avec vos données à travers des objets. Autrement dit, il s’agit d’un programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet. De ce fait, faut-il en utiliser un ou faut-il simplement écrire toutes ses requêtes à la base données avec le langage SQL ?

Il s’agit en effet d’un débat qui s’installe très souvent entre les développeurs. Les ORM sont venus avec pour vocation : la réduction du code à écrire et à maintenir pour l’informaticien qui manipule la base de données depuis son logiciel, l’homogénéité du code objet et l’accélération du temps de développement. Néanmoins, bien que ces avantages semblent très souvent les plus recherchés par les développeurs, les spécialistes des bases de données leur trouvent beaucoup de défauts. On pourrait insinuer que les développeurs y voient surtout une simplification et une accélération de leur temps de développement, mais la bonne pratique des ORM est certainement dans une utilisation modérée et circonstanciée de ces outils.

Selon Eli Bendersky, programmeur et contributeur à l’open source, les ORM, malgré les avantages qu’on peut leur citer, sont limités lorsqu’il s’agit de travailler sur des modèles de bases de données plus complexes que le classique CRUD. Son analyse s’est basée sur une comparaison de l’utilisation du SQL simple et ensuite d’un ORM pour manipuler une base de données d'une application écrite avec le langage de programmation Go. Il a tiré la conclusion selon laquelle l’utilisation ou non d’un ORM dépend des avantages des dépendances supplémentaires en fonction de l’effort. En d’autres termes, cela a-t-il un sens d'implémenter vous-même presque toutes ou toutes les fonctionnalités d'un projet, ou est-il préférable d'utiliser la pléthore de bibliothèques disponibles pour de nombreuses sous-tâches que le projet doit effectuer ?


D’après ce qu’explique Bendersky, les avantages des ORM résident principalement dans la réduction du code à écrire, ce qui les laisse avec un lot considérable d’inconvénients. Pour lui, les ORM évitent un codage fastidieux. Ils vous font faire environ 50 % d’économie en code centré sur la base de données, ce qui n’est pas banal et peut faire une réelle différence pour certaines applications. Les autres avantages qu’on peut citer pour les ORM sont plus remarquables avec la plupart des applications simples, mais lorsqu’il s’agit de schémas de bases de données plus complexes ou d’applications avec des niveaux d’abstractions plus avancées, les ORM montrent tout de suite leurs limites.

Par exemple, certains avancent qu'ils ne permettent pas de gérer les requêtes un peu complexes (jointures, groupements), les transactions ou les traitements par lots et parfois, les relations many-to-many sont également difficiles à gérer. Ils créent en plus une forte dépendance à l’outil ORM utilisé. En général, ils causent des problèmes lorsque la base de données n’est pas faite dans les règles de l’art. Dans son cas, Bendersky a utilisé l’ORM Gom pour le langage de programmation Go, qui selon lui présente les mêmes inconvénients. Après son analyse comparative, il a noté les inconvénients suivants liés aux ORM :

  • une autre couche à apprendre, avec toutes les particularités, la syntaxe spéciale, les balises magiques, etc. Ceci est principalement un inconvénient si vous êtes déjà familiarisé avec SQL lui-même ;
  • même si vous n'avez pas l'habitude d'utiliser SQL, il existe une vaste banque de connaissances et de nombreuses personnes pouvant vous aider à trouver des réponses. Tout ORM est un savoir beaucoup plus obscur que beaucoup ne partagent pas, et vous passerez beaucoup de temps à chercher comment forcer les choses ;
  • déboguer les performances des requêtes est un défi, car l’abstraction se trouve à un niveau plus éloigné du métal. Il faut parfois un peu de peaufinage pour que l'ORM génère les requêtes qui vous conviennent, ce qui est frustrant lorsque vous connaissez déjà les requêtes dont vous avez besoin.

Enfin, dit-il, il existe un inconvénient qui ne devient apparent qu'à long terme. Il estime que le SQL reste à peu près constant au fil des ans, mais les ORM sont spécifiques à la langue et tendent également à apparaître et à disparaître tout le temps. Chaque langage populaire dispose d’une grande variété d’ORM. Lorsque vous passez d'une équipe/entreprise/projet à un autre, vous pouvez être amené à changer de fournisseur, ce qui constitue un fardeau mental supplémentaire. Ou vous pouvez changer complètement de langue. Pour lui, le SQL est une couche beaucoup plus stable qui vous accompagne dans vos équipes/langages/projets et ceci, peu importe les circonstances.

Enfin, il finit en réitérant que l’attrait le plus important des ORM est la réduction du code passe-partout, mais mis à part cela, dit-il, il existe de nombreux inconvénients à utiliser un ORM. Selon lui, les langages de programmation comme le langage Go font aujourd’hui l’effort de proposer un bon interfaçage avec le SQL. Il faudrait donc éviter les dépendances inutiles aux ORM ou à d’autres bibliothèques au risque de perdre la fluidité voulue pour son projet. « Je ne pense pas qu’un ORM me soit utile dans un langage comme Go, qui possède déjà une bonne interface SQL, principalement portable sur les bases de données. Je préférerais passer un peu plus de temps à taper mes requêtes, mais cela me fera gagner en performance après. Mes requêtes seront optimisées et, plus important encore, le débogage sera plus facile à effectuer », a-t-il déclaré.

De même, selon certains, les gains de productivité (du moins au tout début du développement) avec l’utilisation d’un ORM sont indéniables. Par contre, a écrit l’un d’entre eux, « ce que j'ai toujours recherché, ce sont des frameworks qui vous donnent un ORM mais rendent aussi les requêtes de bas niveau très faciles, normalement à travers un constructeur de requêtes et vous permettant de passer d'un niveau d'abstraction à un autre. Si je devais choisir, je préfère les bibliothèques qui vous donnent d’abord le niveau le plus bas d’abstractions, puis s’appuient sur celles-ci pour offrir une approche ORM basée sur la programmation orientée objet (ce à quoi, selon moi, la plupart des gens pensent quand on dit “ORM”) ». Il cite TypeORM comme l’une des meilleures bibliothèques qu’il a utilisées.

Mais dans le même temps, un autre indique que TypeORM avait été écrit par des personnes qui ne connaissaient pas vraiment le SQL. Pour lui, les ORM sont excellents pour les tâches répétitives, en particulier lorsqu'ils sont intégrés à des frameworks. Cependant, dit-il, la présence d’un ORM peut empêcher le plus souvent d'accéder aux aspects les plus avancés d’une base de données.

Source : Billet de blog

Et vous ?

Quel est votre avis sur le sujet ?
Devrait-on continuer d'utiliser les ORM, selon vous ? Pourquoi ?

Voir aussi

Prisma, un outil ORM pour le développement des applications modernes. Pourra-t-il remplacer les outils ORM traditionnels ?

L'ORM serait-il une « grosse erreur » ? Selon un développeur, « l'ORM est un anti-pattern qui ne devrait pas exister »

« ORM or not ORM » : faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de walfrat
Membre du Club https://www.developpez.com
Le 15/05/2019 à 9:41
Pour moi les ORM excelle dans les points suivant :

  • Opération d'écriture => pas de SQL à faire nous-même => gros gain de temps.
  • Cache : le cache transactionnel permet de séparer les développements tout en évitant le double requetage de certain élément s'il sont déjà chargés par l'ORM


Les points à surveiller sont les suivant

  • Ne pas vouloir charger trop de données d'un coup ou pas assez, et donc ne pas tirer parti du cache ou faire exploser la RAM.
  • Cache inter-transaction : faire attention avec celà.
  • Recherche : on peut faire des choses relativement puissante, surtout pour aller de paire avec des filtrage typique d'écran de recherche.


Je met les éléments suivant à part :

  • Performance de base (N+1 select, traitement pas batch typiquement) => manque de compétence (ou d'un guide) du développeur sur l'outil plutôt qu'autre chose.
  • Requetage complexe : Je ne pense pas que les ORM avaient prévu (et c'est toujours le cas) de remplacer le SQL dans tous les cas d'utilisation. Il faut donc faire preuve de jugement et passer au SQL quand c'est nécessaire. Par exemple les requête récursive sont possible en SQL autant s'en servir s'il le faut.
  • En Java par exemple certains élément d'ORM sont pas 100% compatible sur les SGBD : il s'agit de problème de Driver JDBC pas des ORM.
Avatar de Michel.Priori
Membre éclairé https://www.developpez.com
Le 15/05/2019 à 10:09
Avouons que, la plupart du temps, le problème ne vient pas de l'outil, mais de la méthode.
Et pour être plus exact de la qualité de ce comment la "conception" est menée.

Pour avoir un ORM il faut un modèle objet.
Or, comment est conçu ce modèle ?
La plupart du temps : "à l'arrache"
Quelle est la portée du modèle ?
La plupart du temps : "limitée au développement"

Franchement quand on a dépassé ça, on a franchi un grand pas.

Je suis sidéré par le silence (ou par les tentatives de détournement d'attention) lorsqu'on demande à consulter les documents "conceptuels" (diagrammes UML, MCD, ...)
Un peu comme le cahier des charges ; tout le monde en parle, personne ne l'a lu

La doxa du moment est de développer toujours, et encore, plus vite.
Tout faire "pour hier", sans répits, sans documentation, sans partages, sans contradictions, ne peut pas aller dans le sens de la qualité.
Avatar de Cincinnatus
Membre éprouvé https://www.developpez.com
Le 15/05/2019 à 10:15
Comme déjà indiqué ci-dessus, il faut savoir prendre différents outils selon les circonstances :
- Mapping ORM pour les opérations CRUD de base, pour ne pas créer de requêtes basiques, qui n'apportent pas de valeur ajoutée, et faciliter les évolutions des modèles de données,
- requêtes sur-mesure pour tout ce qui ressort des requêtes un peu évoluées, avec optimisation si besoin.

ça nécessite juste les compétences nécessaires pour ce métier, et savoir choisir les bons outils (dédicace à un de mes anciens formateurs)
Avatar de CaptainDangeax
Membre confirmé https://www.developpez.com
Le 15/05/2019 à 10:38
Je travaille sur le maintien en conditions opérationnelles d'un logiciel ancien. Tellement ancien que l'archivage automatique est en PLS depuis 5 ans. Il y a une couche logicielle entre la BDD et le produit. Le nombre de données à archiver est tellement important qu'à chaque tentative de purge, la couche logicielle fait un memory full. J'ai donc demandé à mon équipe de développement de ré-écrire la fonction de purge en pure SQL. Voilà...
Avatar de al1_24
Modérateur https://www.developpez.com
Le 15/05/2019 à 10:51
Utiliser un ORM, pourquoi pas ? Mais surtout commencer par former correctement les développeurs Java à l'écriture des requêtes et au fonctionnement sous-jacent d'un SGBD.
Non, ce n'est pas plus simple de filtrer les lignes dans le code Java. Ca encombre juste inutilement le réseau.
Non, ce n'est pas plus efficace d'effectuer les vérifications de validité dans le code Java. Ca permet juste de laisser la capacité d'enregistrer des données invalides dans la base de données.
Non, ce n'est pas utile de calculer des totaux dans le code Java pour les enregistrer dans la table. C'est seulement une manière de riquer à terme d'avoir une information calculée stockée différente du contenu réel des données.
On calcule l'âge du prospect au moment de son enregistrement dans la base. Ca ira plus vite que de le calculer à chaque fois qu'on en a besoin...
Avatar de MaitrePylos
Modérateur https://www.developpez.com
Le 15/05/2019 à 11:35
Le souci, n'est pas vraiment l'utilisation d'un orm, mais bien la conceptualisation de la db (MCD, MLD).
Car si l'application deviendra obsolète les données seront toujours utile.
Je migre une source de données de 1998 et je pleure tous les jours
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 15/05/2019 à 12:10
SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.
Avatar de MaitrePylos
Modérateur https://www.developpez.com
Le 15/05/2019 à 12:12
Citation Envoyé par Sodium Voir le message
SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable. Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.
Sauf que les ORM font des requêtes SQL
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 15/05/2019 à 12:22
Tout comme le code devient du binaire, personnellement je préfère utiliser un code propre et compréhensible plutôt que du binaire

Sql est un peu l'assembleur des BDDs tout comme JavaScript est l'assembleur du web côté client.
Avatar de wallas00
Candidat au Club https://www.developpez.com
Le 15/05/2019 à 12:30
Voilà plus de 5 ans que je suis "abonné" à developpez.net sans jamais m'être inscrit(**t'aurais du le rester)... Mais les récents post et leurs commentaires associés suscitent un accueil de moins en moins "chaleureux" de ma part.

Je vais commencer par un jugement de valeur sur l'avis de M. Eli Bendersky:

Lorsque je constate que les langages de programmation et ORMs choisis comme base de comparaison et/ou fer de lance de la famille des ORMs sont respectivement Go + TypeScript et Gom + TypeORM, alors je me demande si je dois gerber ou raler.
Voici plus d'un an que je code en TypeScript côté Back(NestJS), et je peux vous dire que typeorm est mieux que l'éditeur de requête SQL basique(knexJS), indépendamment de la complexité du système; cependant, mon expérience avec l'ORM de django est à des années lumières du reste en terme de plaisir d'utilisation et d'efficacité. J'ai le même retour venant des utilisateurs(mes amis & collègues) d'Active Record(Ruby - Rail), ainsi que que des utilisateurs d'Entity Framework.

Comme d'habitude, dans mon entourage proche, les ORMs Java marchent bien, mais sont très critiqués pour leur lourdeur.

En outre, lors du test de prisma(orm extrêment prométeur) avec Go, j'ai eu l'impression de traîner un boulet .
Mon opinion sur Go est assez catégorique et peut-être biaisée; écrire du code business avec Go c'est presque pareil que de le faire en C.

Enfin, un jugement plus factuel et technique:

Avoir des connaissances sur la base de données choisie pour le développement de votre application:
- Relationnelle? Orienté document? Graphe? Entrepôt? Qu'est ce qui correspond le mieux à vos besoins?
- Comprendre la notion de transaction.
- Développer le bon sens dans la construction des requêtes(optimiser en fonctions de son modèle de données, utiliser correctement les alias...).
- savoir si vos requêtes sont optimisées automatiquement par le moteur de calcul de l'ORM.
- connaître les stratégies de caching de requêtes proposées par l'ORM.
- savoir quel driver vous utilisez: est-ce qu'il génère des requêtes textuelles destinées à être réinterprétées par l'engine de la DB ou bien des requêtes sérialisées...

Orm ou pas, l'idée est:
- d'en apprendre toujours plus sur les outils mis à notre disposition,
- pour produire des solutions de qualité à nos problèmes (CRUD, traitement, maladie, mariage, etc ...)
Contacter le responsable de la rubrique SGBD & SQL

Partenaire : Hébergement Web