Eh bien, une chose qui est importante à faire chaque fois que nous avons une discussion comme celle-ci est de distinguer clairement entre les mappeurs relationnels d'objets ("ORM") et les couches d'abstraction de base de données . Un ORM est une sorte de couche d'abstraction de base de données, mais toutes les couches d'abstraction de base de données ne sont pas des ORM. Un bon outil à étudier pour comprendre cela est la populaire bibliothèque SQLAlchemy de Python , qui se présente comme une "boîte à outils SQL et mappeur relationnel d'objet" (mon gras), avec l'idée que ce sont des choses différentes. Comme ils l'ont mis dans leur page de fonctionnalités clés :
Aucun ORM requis
SQLAlchemy se compose de deux composants distincts, appelés Core et ORM . Le Core est lui-même une boîte à outils d'abstraction SQL complète, fournissant une couche d'abstraction fluide sur une grande variété d'implémentations et de comportements DBAPI, ainsi qu'un langage d'expression SQL qui permet l'expression du langage SQL via des expressions Python génératives. Un système de représentation de schéma qui peut à la fois émettre des instructions DDL et introspecter les schémas existants, et un système de types qui permet tout mappage des types Python aux types de base de données, complète le système. Le mappeur relationnel objet est alors un package facultatif qui s'appuie sur le noyau.
La première page décrit l'ORM comme ceci:
SQLAlchemy est surtout connu pour son mappeur objet-relationnel (ORM), un composant facultatif qui fournit le modèle de mappeur de données, où les classes peuvent être mappées à la base de données de manière ouverte et multiple - permettant au modèle objet et au schéma de base de données de se développer dans un manière découplée proprement depuis le début.
L'idée clé d'un ORM est d'essayer de combler le fameux décalage d'impédance relationnelle-objet . Cela signifie définir les relations entre les classes définies par l'utilisateur et les tables dans un schéma de base de données et fournir des opérations "d'enregistrement" et de "chargement" automatiques pour les classes de votre application.
En revanche, les couches d'abstraction de base de données non ORM ont tendance à être plus engagées dans le modèle de données relationnelles et dans SQL, et pas du tout à l'orientation objet. Ainsi, au lieu de présenter des «mappages» entre les tables et les classes et de cacher le schéma de la base de données au programmeur, ils ont tendance à exposer la base de données au programmeur mais avec de meilleures API et abstractions. Par exemple, les constructeurs de requêtes SQL vous permettent de générer des requêtes SQL complexes par programmation, sans manipulation de chaîne, comme ceci ( un exemple de la bibliothèque jOOQ pour Java ):
// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
.from(BOOK)
.join(AUTHOR)
.on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.PUBLISHED_IN.equal(1948))
.fetch();
Maintenant, le framework Play ne semble pas être à 100% en accord avec ce que je viens de décrire , mais leur argument semble être dans cet espace général: travailler directement avec le modèle relationnel au lieu de le traduire en classes et inversement.
La bibliothèque jOOQ mérite d'être étudiée comme contrepoint aux ORM. Ils ont également quelques entrées de blog pertinentes qui valent la peine d'être lues: