IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

96PARTAGES

14  1 
Êtes-vous pour l'utilisation d'un ORM (mapping objet-relationnel) ? Pourquoi ? Partagez vos avis
Oui
52 %
Non
47 %
Pas d'avis
3 %
Voter 116 votants
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-nous-la !

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...
11  1 
Avatar de MaitrePylos
Modérateur https://www.developpez.com
Le 15/05/2019 à 14:31
Citation Envoyé par Pyramidev Voir le message
Ici, passer par un ORM permet de changer plus facilement de SGBD, car il n'y a pas besoin de réécrire la requête.
Ha le vieux fantasme de changer de moteur de DB à la volée.
Si cela est vrai pour des outils de gestion (Drupal, CMS ou autre), c'est à dire des outils qui se veut généraliste.
Cela est nettement moins vrais pour des outils spécialisé.
11  1 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 22/05/2019 à 11:26
Citation Envoyé par MaitrePylos Voir le message
Que viennent ici les gens qui ont 200000 visiteurs mois, avec des serveurs qui font du load balancing en appli et DB réplicatif sur des données de plusieurs terras et on pourras comparer.
+1000
Il ne faut pas s'inquiéter, de toute façon dès que cela devient sérieux en prod, partout où je suis passé, on se rapproche finalement au plus près du moteur SGBDR. C'est inhérent et quand bien même une tonne de pingouins critiquent l'écosystème SQL, on n'a pas fait guère mieux depuis pour avoir une gestion de données performante.

Donc faut rester relax et lucide, le SQL est incontournable pour durer dans le métier. Ceux qui s'imaginent pouvoir s'en passer durant une vie de développeur sont des doux rêveurs.
C'est comme tout : ça s'apprend
11  1 
Avatar de blbird
Membre chevronné https://www.developpez.com
Le 16/05/2019 à 21:33
Citation Envoyé par Sodium Voir le message
Allez, on va te dire oui et te donner une tape sur la tête si ça peut te faire plaisir. Maintenant va jouer ailleurs, on est là pour discuter de fond et pas pour faire du bashing de cours de récré.
Mais tu ne peux pas discuter du fond puisque tu ne connais même pas les techno dont on parle.
10  1 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 14/09/2019 à 16:29
Citation Envoyé par Sodium Voir le message
Il est également très difficile à debugger. Quand une requête SQL contient une erreur, le message va généralement être "y a un truc qui va pas entre les caractères 10 et 320, démerde-toi avec ça lol".
Ca fait combien de siècles que vous n'avez pas fait de SQL
9  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 03/10/2019 à 16:20
Je pense que le tour de la question a été largement fait, il y a quelques bons arguments de part et d'autres mais noyés dans un dialogue de sourds depuis quelques pages, aussi je verrouille cette discussion.
9  0 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 15/05/2019 à 17:38
1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...

3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.
14  6 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 16/05/2019 à 15:12
C'est déroutant cette réticence à vouloir apprendre le SQL.

Apprendre des nouveaux langages de programmation c'est courant, et entre Java, Ruby, Python et les centaines d'autres langages c'est quand même un travail d'apprentissage conceptuel et syntaxique qui est loin d'être négligeable. Quand on regarde le CV d'un développeur, on trouve régulièrement de nombreux langages dans sa bannette.

Vous préférez apprendre encore plus de langages spécifiques en rajoutant des ORM au lieu d'apprendre le SQL une fois pour toute, qui reste un langage comme un autre avec ses concepts ensemblistes et sa grammaire.

Certes, les dialectes sont différents d'une base à une autre, mais la logique est toujours la même et le tronc commun est solide et à tendance à grossir avec le temps.
Apprendre les différences entre plusieurs SGBD c'est relativement anecdotique et je le perçois comme un argument paresseux, si on sait ce qu'on cherche en un coup de votre moteur de recherche préféré on trouve. Voyez-ça comme une nouvelle bibliothèque à manipuler.

Est-ce le concept du L4G qui vous effraie ?
Peur de sortir de sa zone de confort ?

Car ceux qui s'y mettent s'en sortent tout à fait honorablement.
10  2 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 11/09/2019 à 17:52
Citation Envoyé par Sodium Voir le message
Et le SQL, eh bien c'est dégueulasse à lire, (sans déconner, ces "CASE WHEN", omondieu), à écrire, et à générer. Un ORM c'est clair, standardisé, facile à lire et à apprendre. Je ne vois aucune raison valable de sans passer quand l'utiliser est possible.
Ca c'est un point de vue purement subjectif et quelque peu de mauvaise fois.

Le SQL est le seul langage de haut niveau que je connaisse qui soit lisible (jusqu'à la norme SQL92 tout du moins) par une personne n'ayant pas la moindre connaissance informatique.
Seule une rapide explication sur l'algèbre ensembliste est nécessaire.

Tout le reste, c'est purement de l'anglais exprimé aussi simplement qu'il est possible…

Après, pour ce qui est des fonctions de fenêtrages et autres common table expressions, je veux bien accepté que ça se lise pas aussi simplement sans plus d'explication… mais ça reste toujours moins compliqué à lire que n'importe quel autre langage de programmation, qu'il soit objet ou non.

Quant au CASE WHEN que tu sembles avoir en horreur, il est justement là pour éviter d'interroger plusieurs fois successivement le SGBD afin d'obtenir le résultat désiré… ça permet juste de gagner en clarté dans le code appelant, et surtout en performances…

Il est toujours plus aisé de maintenir une seule requête SQL appelée par un bout de code que de maintenir 25 requêtes appelées dans 25 bouts de code imbriqués…
8  0 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 14/09/2019 à 12:10
Citation Envoyé par Sodium Voir le message
Quel que soit le sujet, quand des "experts" arrivent pour hurler qu'il ne faut JAMAIS faire quelque chose, c'est qu'ils ont généralement une vision très limitée du domaine.

C'est bien beau d'être calé en bases de données, mais quand on n'a aucune connaissance de la réalité du développement et de la maintenance d'applications, je ne vois pas bien l'intérêt.
Que savez-vous de la connaissance des uns et des autres sur le développement et la maintenance
8  0