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

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?

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".

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.

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.

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.

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.

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é.

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.

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.