L'ORM est-il un anti-modèle? [fermé]

58

J'ai eu une discussion très stimulante et intéressante avec un collègue sur ORM et ses avantages et inconvénients. À mon avis, un ORM n'est utile que dans les cas les plus rares. Tout du moins selon moi.

Mais je ne veux pas énumérer mes propres arguments pour le moment. Je vous demande donc ce que vous pensez de l'ORM? Quels sont les avantages et les inconvénients?

derphil
la source
3
Avez-vous lu ceci: seldo.com/weblog/2011/08/11/orm_is_an_antipattern ?
FrustratedWithFormsDesigner
2
Oui. Sauf si vous avez une application CRUD générique qui ne fait rien de valeur avec la base de données, dans ce cas, vous ne devriez pas utiliser de base de données relationnelle.
Raynos
1
@derphil: Vous voudrez peut-être réduire la largeur, sinon ce sera fermé. Si vous croyez que c'est un anti-modèle, expliquez peut-être pourquoi et demandez ensuite dans quelles situations cet anti-modèle est-il approprié (mais cela pourrait quand même être trop large).
FrustratedWithFormsDesigner
2
@derphil, il y a beaucoup de contre-arguments dans les commentaires de cet article de blog, les avez-vous lus?
Péter Török
2
Et juste une autre preuve de la raison pour laquelle vous n'avez pas besoin d'un ORM: medium.com/@wrong.about/you-dont-need-an-orm-7ef83bd1b37d
Zapadlo

Réponses:

83

Il existe un ensemble assez important et varié de difficultés conceptuelles et techniques lorsque vous essayez d'approcher une base de données relationnelle sous un angle orienté objet. Ces difficultés sont collectivement appelées inadéquation impédance relationnelle-objet et l'article connexe de Wikipedia est extrêmement informatif. L'article en identifie quelques-uns, je ne vois pas de moyen sensé de les décrire ici. Juste pour vous donner une idée générale, ils sont catalogués comme suit:

  • Mismatches
    • Concepts orientés objet
    • Différences de types de données
    • Différences structurelles et d'intégrité
    • Différences de manipulation
    • Différences transactionnelles
  • Résoudre le désadaptation d'impédance
    • Minimisation
    • Architectures alternatives
    • Compensation
  • Contention
  • Différences philosophiques

Je pense que si vous prenez le temps de lire l'article, vous comprendrez que le fait que l'ORM soit parfois décrit comme un anti-modèle est en fait inévitable. Les deux domaines sont si différents que toute approche visant à traiter l'un comme l'autre est par défaut un anti-modèle, en ce sens qu'un anti-modèle est un modèle allant à l'encontre de la philosophie d'un domaine.

Mais je ne pense pas que le terme devrait s'appliquer à tout ce qui agit essentiellement comme un pont entre deux domaines extrêmement différents. Marquer un motif comme anti-motif n'a de sens que dans son domaine. Donc, la question de savoir si c'est un anti-modèle ou non est sans importance.

Mais est-ce utile? Oui, ORM est l’un des anti-modèles les plus utiles. Vous comprendrez pourquoi uniquement si vous vous trouvez dans une situation pratique où vous devrez échanger des bases de données dans un projet. Ou même mettre à niveau vers une autre version de la même base de données. ORM est l'une de ces choses que vous ne comprenez parfaitement que lorsque vous en avez réellement besoin.

Bien entendu, comme tout ce qui est utile, ORM est très sujet aux abus. Si vous pensez que cela remplace en quelque sorte le besoin de tout savoir sur la base de données sur laquelle vous travaillez, il reviendra et vous mordra. Dur.

Enfin, laissez-moi brancher une autre de mes réponses sans vergogne , sur le sujet "Le modèle ActiveRecord suit-il / encourage-t-il les principes de conception SOLID?" question, qui pour moi est une question beaucoup plus pertinente que "est-ce un anti-modèle".

Yannis
la source
5
+1 pour avoir utilisé l'expression "décalage d'impédance". Buzzwords pour les geeks, mais je les aime aussi!
Hardmath
Totalement d'accord ... vérifiez ce lien est si bien expliqué: seldo.com/weblog/2011/08/11/orm_is_an_antipattern
sandino
42

Cela revient à se demander "est-ce qu'une perceuse électrique est un anti-modèle?". Les ORM ont pris une bonne place dans ma boîte à outils, réduisant mon code standard et je suis encore capable d’utiliser du code SQL personnalisé si nécessaire. Donc, si c'est un anti-modèle, contre quel modèle va-t-il?

Ma réponse est non, il existe de nombreux ORM matures qui vous simplifient la vie et rendent votre code plus compréhensible. Cela signifie en aucun cas que vous n'avez pas besoin de comprendre le langage SQL, bien au contraire.

Otávio Décio
la source
11
+1 moi aussi je pense que c'est très utile, il y a un apprentissage d'une courbe. Mais il est très agréable de ne pas avoir à peupler manuellement des pojos, etc.
NimChimpsky
18

Je voudrais hésiter à appeler quelque chose un "anti-modèle" qui a d'abord été appelé un modèle par Martin Fowler et qui a depuis été adopté dans presque tous les langages de programmation modernes. (Voir l'article de Wikipedia sur ActiveRecord .)

Un bon ORM peut conduire à beaucoup moins de code (et beaucoup moins de répétition) dans un projet, et rien n’est aussi fortement corrélé avec les bogues que la quantité de code original.

Les ORM sont généralement conçus pour traiter les cas d’utilisation les plus courants pour travailler avec des bases de données. Les requêtes complexes doivent encore être écrites explicitement. Mais je déconseillerais fortement l'écriture de requêtes explicites pour chaque interaction de base de données. Dans la plupart des cas, c'est une perte de temps.

Nathan Long
la source
12
"J'hésiterais à aller à l'encontre des arguments des autorités"
Raynos
3
@Raynos: Vous voulez dire ... vous dites que ... Fowler aurait pu être ... FAUX?!?! choc & halètement Hérésie! Blasphème!! : P;)
FrustratedWithFormsDesigner
9
@Raynos - Peut-être que l'autorité n'est pas le meilleur argument, mais le PO a déclaré "selon mon expérience". Il s’agit essentiellement d’un appel à l’autorité personnelle. J’estime donc raisonnable de contrer par un appel à l’autorité et au consensus. En outre, le terme "anti-modèle" est lui-même sur les opinions. J'ai donné des exemples de ce que pensent les autres.
Nathan Long
3
@NathanLong Je viens de souligner que la popularité et la correction sont orthogonales.
Raynos
1
FWIW Data Mapper est probablement le modèle le plus proche d'un ORM. ActiveRecord est un modèle différent, mais certainement lié.
JasonTrue
11

Utiliser un ORM au lieu d'apprendre SQL est une très mauvaise idée. Si vous ne connaissez pas exactement le type de code SQL généré, si vous ne comprenez pas les problèmes de N + 1 et comment l'optimiser, cela causera certainement plus de tort que de bien. Je pense cependant que je suis beaucoup plus productif avec un ORM. Je préfère Rails ActiveRecord, qui n'essaie pas de prétendre qu'il n'y a pas de base de données et ne vous gêne pas si vous avez juste besoin d'écrire en SQL. Je crains cependant que certaines personnes puissent faire confiance aux idiomes qu’elles voient trop profondément, sans une compréhension profonde de ce qu’elles font.

Jeremy
la source
11

Mon expérience: J'utilise NHibernate avec Linq2NHibernate.

Avantages:

  • Il se débarrasse de "Magic Strings", ou du moins offre un endroit unique pour les poser
  • Cela me permet de travailler dans un paradigme OO tout le temps
  • Le code est plus facile à lire
  • Le code construit sur le dessus est plus facile à changer
  • Il vous permet d’échanger votre base de données relationnelle réelle sans avoir à gérer 2 référentiels distincts (rarement fait, mais c’est un gros avantage si vous en avez besoin).

Les inconvénients:

  • Le code est plus difficile à écrire , car
  • Ce n'est pas une abstraction suffisante - vous devez toujours être intimement au courant de ce qu'il fait en arrière-plan

Je dirai que cela ne tient pas la promesse que la plupart des gens espéraient au départ. Je ne voudrais pas reprocher à quelqu'un de dire que c'est un anti-modèle. Dans mon cas, je dois toujours effectuer des tests d'intégration sur une base de données SQLite pour vérifier que mes requêtes Linq2NHibernate fonctionnent réellement. Donc, vraiment, si vous faites de toute façon des tests d’intégration sur une vraie base de données relationnelle, cela élimine en quelque sorte le problème des "chaînes magiques".

Si je devais commencer un nouveau projet, je ne suis pas sûr d'utiliser un ORM ou non. Je le ferais probablement, mais je ne peux pas dire avec certitude que vous devriez. Je dirais que c'est comme la différence entre choisir C ++ ou Java / .NET pour votre projet: allez-vous avoir besoin de la flexibilité que vous obtenez en travaillant à un niveau inférieur ou préférez-vous travailler à un niveau supérieur et (supposément) être plus productif? La réponse normale est de travailler à un niveau aussi élevé que possible . Cela signifie généralement utiliser un ORM.

Scott Whitlock
la source
6

La force d'un ORM est qu'il vous permet de modéliser le comportement d'une application à l'aide de techniques orientées objet. Dans un monde soigneusement conçu, vous disposez d’une couche de l’application où le langage de l’entreprise correspond parfaitement au langage de l’équipe de développement. L'ORM est un catalyseur de cela, si l'ORM est utilisé judicieusement.

La faiblesse est que le nombre de personnes qui bénéficient réellement d'une programmation orientée objet est plutôt réduit. Beaucoup de gens écrivent des spaghettis et des boulettes de viande, avec des objets fortement couplés qui ont peu de comportement et qui aboutissent à des classes hideuses "Service" et "Manager" à 8000 lignes, et ce code est souvent si compliqué que tout le monde a peur. de le changer parce qu'ils ne peuvent pas comprendre quels seront les effets secondaires.

De plus, beaucoup de gens ne comprennent pas vraiment le modèle relationnel. Un ORM ne les aidera pas à l'obtenir, et cela ne les aidera pas en faisant abstraction du modèle relationnel. Cela vous permet simplement de vous concentrer dès le début sur votre couche de domaine et de bien le faire avant de vous préoccuper de la conception de la base de données. S'ils sont bien appliqués, à l'aide d'outils de migration de schéma judicieux, ORM peut vous aider à empêcher l'accumulation de dettes de code.

J'ai construit des applications dans lesquelles un ORM conservait un code d'application simple, lisible et testable, avec des performances raisonnables. J'ai également maintenu des applications où le modèle était mal utilisé et le code compliqué, indestructible, lent et fragile; il s'avère que l'ORM lui-même a peu à voir avec cela, sauf qu'au lieu d'écrire un code incorrect qui modélise mal le domaine d'application, l'équipe d'ingénierie héritée écrit un code incorrect qui modélise mal le domaine d'application ET un code de couche de service qui néglige l'ensemble la valeur que leur ORM pourrait leur fournir.

Les ORM ne vous rendront pas plus intelligent, mais entre les mains du bon développeur, vous pouvez générer un code plus facile à gérer et de meilleure qualité.

JasonTrue
la source
Je pense que cela complique l’utilisation d’un modèle ORM en tant que modèle d’accès à une base de données et d’un module ORM en tant que générateur de code sophistiqué pour faciliter et améliorer l’accès aux bases de données.
gbjbaanb
Je ne suis pas sûr de ce que vous entendez par là. Votre commentaire n'a pas beaucoup de sens pour moi.
JasonTrue
En cela, un ORM constitue un excellent moyen d'accéder à une base de données avec une tonne de travail acharné mais si vous l'utilisez comme motif de conception pour prétendre qu'une base de données est une collection d'objets, elle commence à tomber. C'est ce que je pensais que vous disiez.
gbjbaanb
Je ne pense pas avoir jamais recommandé d'utiliser un ORM pour prétendre que vous disposiez d'un magasin d'objets magiques qui ne vous oblige pas à comprendre le fonctionnement de la base de données. J'ai dit exactement le contraire: si vous comprenez bien la programmation orientée objet ET le fonctionnement des bases de données, un ORM peut vous aider à produire du code plus facilement maintenable.
JasonTrue
5

Peut-être que la réponse se trouve dans l'inverse de votre question: est- ce une bonne idée de stocker les données de votre application dans autre chose qu'une base de données relationnelle? Quels problèmes éliminez-vous et quels autres problèmes allez-vous résoudre? Pouvez-vous vivre sans la possibilité de croiser facilement vos données (jointures) ou de filtrer rapidement les enregistrements souhaités en fonction de plusieurs critères? N'avez-vous pas besoin d'un support solide pour les transactions (en supposant que votre alternative ne l'ait pas)? Toutes les applications n'ont pas besoin d'un magasin de données toujours cohérent et complet.

Je pense que le véritable anti-modèle ici peut-être utiliser une base de données relationnelle quand vous n'en avez pas besoin. Si vous en avez besoin, vous avez besoin de l'ORM, et ce n'est certainement pas un anti-modèle.

RGT
la source
1
Bien que je convienne que l'utilisation d'une base de données relationnelle si vous n'en avez pas besoin est une mauvaise idée, aujourd'hui, si vous en utilisez une, vous avez besoin d'un ORM, c'est ridicule!
HLGEM
1
Euh, alors comment allez-vous obtenir vos données dans et hors de la base de données? Quelque part, quelque chose va devoir mapper vos objets sur la structure relationnelle et les recréer lorsqu'ils sont lus à partir de la base de données. Même si vous écrivez à la main des requêtes et copiez les données dans des jeux de résultats, vous effectuez une opération ORM.
TMN
1
Utiliser des procédures stockées (le seul moyen acceptable d'insérer tout type de données financières pour des raisons de contrôle interne) pour effectuer toutes les manipulations de base de données n'est pas ORM dans mon esprit. Je n'ai jamais vu aucune valeur à un ORM pour quelqu'un qui connaît bien SQL. Je n'ai jamais non plus travaillé sur un système (et je travaille avec des applications d'entreprise très complexes) qui dépendait fortement d'un ORM. Ils ne sont tout simplement pas assez performants lorsque ce que vous faites est complexe.
HLGEM
6
@HLGEM: Et qu'en est-il des données que vous obtenez de la base de données? Lorsque vous interrogez la base de données relationnelle, ne mappez-vous pas les résultats sur des objets? D'après mon expérience, il existe deux types de projets utilisant des bases de données relationnelles: ceux qui utilisent des ORM tiers et ceux qui incluent leurs propres ORM mal construits.
Carson63000
2
+1 Carson. Vous utilisez une sorte d’ORM, peu importe la situation, à moins de simplement renvoyer des ensembles de données bruts et d’endosser ceux qui recouvrent votre code (l’infraction la plus flagrante de tous les IMHO), car vous devrez toujours mapper les résultats de cette procédure stockée sur des classes, ce qui est exactement ce que vous faites. Les ORM font pour vous.
Wayne Molina
4

ORM est un outil. Comme tous les outils, s’ils sont utilisés correctement, ils fonctionnent assez bien. Lorsqu'il est utilisé de manière inappropriée, il nécessite un plus gros marteau et du ruban adhésif.

Dans le cas du projet en cours sur lequel je travaille, il sera géré par des non-développeurs (ingénieurs en mécanique, pour être plus précis). Il doit donc être simple et facile à comprendre. Il faudra plusieurs années avant que ce groupe dispose d'un budget pour engager des développeurs (en supposant que le prochain président ne supprime pas l'agence concernée), de sorte que les capacités de maintenance futures constituent un facteur majeur dans nos considérations.

Tangurena
la source