
Selon un développeur, « l’ORM est un anti-pattern qui ne devrait pas exister »
Il existe plusieurs design patterns utilisés dans la programmation orientée objet, et certains tellement utilisés qu’ils deviennent presque incontournables lorsqu’on veut apprendre le développement. L’Object Relationnal Mapping (ORM) est l’un de ces patterns à succès. Il permet d’accéder à une base de données relationnelle à partir d’objets. On peut le résumer comme une technique qui crée l’illusion d’une base de données orientée objet à partir d’une base de données relationnelle.
Ce modèle est implémenté dans plusieurs langages de programmation aujourd’hui à tel point qu’il devient une référence dans les livres. Toutefois, dans un article, Yegor Bugayenko, Directeur de technologie à Teamed.io, déclare que « l’ORM est un anti-pattern terrible qui viole tous les principes de la programmation orientée objet ».
Ce n’est pas la première fois que quelqu’un critique l’ORM. Le débat est long et ne date pas d'hier. On lui avait déjà reproché d’être techniquement limité, faible en performances et difficile à apprendre. Toutefois, pour Yegor Bugayenko, l'idée derrière l’ORM est fausse. Selon lui, « son invention était peut-être la deuxième grosse erreur en POO après la référence NULL ».
La raison qu’il donne est simple ; au lieu d’encapsuler l’interaction avec la base de données dans un objet et fournir par conséquent un point d'entrée unique, il fait l’inverse : il définit les routines qui permettent de communiquer avec la base dans l’objet ORM tandis que les données sont extraites « dans la chose que nous ne pouvons même pas appeler un objet ». Ce qui rend la détection des erreurs plus difficile. Mais en plus, « le SQL n’est pas caché » ce qui ajoute au programmeur la contrainte d’en connaître la syntaxe.

Figure : comparaison entre 1) technique utilisée par l'ORM, 2) technique utilisée par les SQL-speaking objects
Selon lui, la solution serait d’encapsuler le tout dans un seul et même objet (comme décrit dans la figure). Cet objet, que Yegor Bugayenko appelle « SQL-speaking object », sera en charge de toutes les opérations et permettra de cacher tous les détails de la communication avec la base de données : « Il n'y a pas de transactions, pas de sessions ou de factories. Nous ne savons même pas si ces objets sont en train de parler avec la base de données ou s’ils gardent toutes les données dans des fichiers textes ».
Dans son article, il présente quelques exemples en insistant sur le fait que les SQL-speaking objects sont plus simples et respectent de loin les principes de l’orienté objet, à l’inverse de l’ORM « qui ne devrait exister dans aucune application, que ce soit une petite application web ou un gros système pour entreprise ».
Source : DZone
Et vous ?

Vous avez lu gratuitement 664 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.