Les ORM sont-ils toujours un anti-pattern ?

• Les ORM (mappers objet-relationnel) sont souvent critiqués comme un anti-pattern dans le développement logiciel.
• Cependant, cette critique est exagérée, et les ORM ne sont pas intrinsèquement mauvais, pas plus que les autres outils logiciels.
• Le véritable problème des ORM vient souvent d’un mauvais usage ou d’une mauvaise compréhension.
• Les ORM et les bases de données relationnelles fonctionnent selon des paradigmes différents, ce qui peut rendre la modélisation des données et des relations complexe.
• Les ORM enfreignent les principes de responsabilité unique (SRP) et de séparation des préoccupations (SoC), mais ces critiques ne constituent pas pour autant des problèmes décisifs.
• Les véritables problèmes des ORM concernent l’efficacité et la visibilité.
• S’ils ne sont pas utilisés correctement, les ORM peuvent être inefficaces, mais ils disposent aussi de fonctionnalités permettant d’optimiser les requêtes et d’améliorer les performances.
• Le problème du N+1, où l’ORM effectue plusieurs allers-retours vers la base de données, peut être atténué grâce à un data loader.
• Le plus gros problème des ORM est la visibilité et le débogage. Ils peuvent ne pas fournir de messages d’erreur clairs, ou rendre les problèmes difficiles à comprendre et à résoudre.
• Lorsqu’ils sont bien utilisés, les ORM peuvent être aussi efficaces que du SQL brut, mais les développeurs doivent exploiter leurs fonctionnalités et leurs équivalents en SQL natif.
• Pour certaines requêtes complexes ou problématiques, il peut être nécessaire de revenir à des requêtes SQL brutes.
• Globalement, les ORM ne sont pas intrinsèquement mauvais, mais ils nécessitent un usage prudent et éclairé pour éviter les problèmes potentiels.

[GN⁺]

Avis Hacker News

• Les limites et inconvénients des ORM, comme l’impossibilité d’utiliser une autre base de données et la nécessité de connaître SQL, font l’objet de critiques.
• Construire la couche de données requête par requête, avec interpolation de chaînes et une approche proche du JDBC brut, est considéré comme une meilleure méthode.
• Les ORM se limitent souvent au mapping de tables et de vues de base, en ignorant les fonctionnalités et capacités avancées de SQL.
• Il existe deux types d’ORM : ceux basés sur le modèle de domaine et ceux qui génèrent un modèle de domaine à partir d’une base de données existante.
• Les ORM comme jOOQ et Hibernate, avec leurs implémentations et fonctionnalités variées, sont utilisés à des fins différentes.
• Les ORM peuvent être utiles dans des applications complexes comportant de nombreuses tables et des relations de clés étrangères appropriées.
• L’utilisation de SQL brut dans des littéraux de chaîne est considérée comme une alternative aux ORM, et il existe aussi des outils capables de générer des wrappers de requêtes.
• Les ORM pragmatiques, qui n’essaient pas de tout dissimuler dans un bundle ou d’introduire leur propre langage de requête, sont préférés.
• SQLAlchemy est salué pour son approche qui fournit une couche de requêtage pratique sans réinventer SQL.
• Sans ORM, les développeurs doivent écrire et maintenir leur propre interface de base de données, ce qui peut entraîner des bugs et des failles de sécurité.
• Les critiques selon lesquelles les ORM enfreignent les principes SOLID sont perçues comme un conflit entre l’enseignement académique et le développement réel.
• Le manque d’expérience ou l’influence de pratiques académiques peuvent provoquer des problèmes et des dépassements de budget.