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 ? 
Envoyé par Pyramidev
