L'ORM est-il un anti-modèle?
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. Alors je vous demande, que pensez-vous 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 non-correspondance d'impédance relationnelle-objet et le article Wikipédia connexe est extrêmement informatif. L'article en identifie un certain nombre, je ne vois aucun moyen sensé de les décrire ici. Juste pour vous donner une idée générale, ils sont catalogués comme:
- Inadéquations
- Concepts orientés objet
- Différences de type de données
- Différences structurelles et d'intégrité
- Différences de manipulation
- Différences transactionnelles
- Résolution de l'inadéquation de l'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 est parfois décrit comme un anti-modèle est en fait inévitable. Les deux domaines sont si différents que toute approche pour 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 qui va à 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 très différents. L'étiquetage d'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 n'a pas d'importance.
Mais est-ce utile? Oui, ORM est l'un des anti-modèles les plus utiles. Vous comprendrez pourquoi seulement si vous vous trouvez dans une situation pratique où vous devrez échanger des bases de données dans un projet. Ou même passez à une autre version de la même base de données. L'ORM est l'une de ces choses que vous ne comprenez pleinement que lorsque vous en avez réellement besoin.
Bien sûr, comme tout est utile, l'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, alors il reviendra et vous mordra. Difficile.
Enfin, permettez-moi de brancher sans vergogne ne autre de mes réponses , sur le sujet "Le modèle ActiveRecord suit-il/encourage-t-il les SOLID?" question, qui pour moi est une question beaucoup plus pertinente que "est-ce un anti-modèle".
Cela revient à demander "une perceuse électrique est-elle un anti-modèle?". Les ORM ont gagné une bonne place dans ma boîte à outils, réduisant mon code passe-partout et je suis toujours en mesure d'utiliser du SQL personnalisé si nécessaire. Donc, s'il s'agit d'un anti-motif, contre quel motif va-t-il?
Ma réponse est non, il existe de nombreux ORM matures qui vous facilitent la vie et rendent votre code plus compréhensible. Cela signifie que vous n'avez pas besoin de comprendre 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 a depuis été adopté dans presque tous les langages de programmation modernes. (Voir l'article Wikipedia sur ActiveRecord .)
Un bon ORM peut conduire à beaucoup moins de code (et beaucoup moins de répétitions) dans un projet, et rien n'est aussi fortement corrélé aux bugs que la quantité de code d'origine.
Les ORM sont généralement conçus pour gérer les cas d'utilisation les plus courants pour travailler avec des bases de données. Il peut être nécessaire d'écrire explicitement les requêtes complexes. Mais je déconseille fortement d'écrire des requêtes explicites pour chaque interaction avec la 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 assez mauvaise idée. Si vous ne connaissez pas exactement le type de SQL généré, si vous ne comprenez pas les problèmes N + 1 et comment l'optimiser, cela causera certainement plus de mal que de bien. Je pense cependant que je suis beaucoup plus productif en utilisant 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 SQL. Je crains cependant que certaines personnes puissent faire confiance les idiomes qu'ils voient trop profondément, sans une compréhension profonde de ce qu'ils font.
Mon expérience: j'utilise NHibernate avec Linq2NHibernate.
Avantages:
- Il se débarrasse des "Magic Strings", ou offre au moins un endroit unique pour les mettre
- 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 maintenir 2 référentiels séparés (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 familier avec ce qu'il fait en arrière-plan
Je dirai que cela ne tient pas la promesse que la plupart des gens espèrent au départ. Je ne voudrais pas blâmer quelqu'un d'avoir dit que c'est un anti-modèle. Je trouve, dans mon cas, que j'ai encore besoin de faire des tests d'intégration avec une base de données SQLite pour m'assurer que mes requêtes Linq2NHibernate fonctionnent réellement. Donc, vraiment, si vous faites des tests d'intégration contre une vraie base de données relationnelle de toute façon, cela élimine le problème des "chaînes magiques".
Si je devais démarrer un nouveau projet, je ne sais pas si j'utiliserais un ORM ou non. Je le ferais probablement, mais je ne peux pas dire avec certitude vous devrait. 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 (soi-disant) être plus productif? La réponse normale est de travailler à un niveau aussi élevé que vous pouvez vous en tirer. 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ù la langue de l'entreprise correspond parfaitement à celle de l'équipe de développement. L'ORM est un catalyseur de cela, si l'ORM est utilisé à bon escient.
La faiblesse est que le nombre de personnes qui obtiennent réellement, vraiment, une programmation orientée objet est assez petit. Beaucoup de gens écrivent des spaghettis et des boulettes de viande, avec des objets hautement couplés qui ont peu de comportement et le comportement se retrouve dans des classes hideuses de "service" et de "gestionnaire" de 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. Il vous permet simplement de vous concentrer sur votre couche de domaine dès le début et de bien le faire avant de commencer à vous soucier trop 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, et ORM peut vous aider à empêcher la dette de code de s'accumuler.
J'ai construit des applications dans lesquelles un ORM a gardé le code d'application simple, lisible et testable, et avait des performances raisonnables. J'ai également maintenu des applications où le modèle était mal utilisé et le code était alambiqué, non testable, lent et fragile; il se trouve que l'ORM lui-même n'a pas grand-chose à voir avec cela, sauf qu'au lieu d'écrire un mauvais code qui a mal modélisé le domaine d'application, l'équipe d'ingénierie héritée a écrit un mauvais code qui a mal modélisé le domaine d'application ET un mauvais code de couche de service qui a négligé tout la valeur que leur ORM pourrait leur apporter.
Les ORM ne vous rendront pas plus intelligent, mais entre les mains du bon développeur, peuvent conduire à un code plus maintenable et de meilleure qualité.
Peut-être que la réponse réside dans l'inverse de votre question: le stockage des données de votre application dans quelque chose autre qu'une base de données relationnelle est-il une bonne idée? Quels problèmes éliminez-vous et quels autres problèmes allez-vous relever? Pouvez-vous vivre sans la possibilité de croiser facilement vos données (jointures) ou de filtrer rapidement les enregistrements que vous souhaitez en fonction de plusieurs critères? Vous n'avez pas besoin d'un support de transaction solide (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 utiliser une base de données relationnelle lorsque vous n'en avez pas besoin. Si vous en avez besoin, alors vous avez besoin d'ORM, et ce n'est certainement pas un anti-modèle.
ORM est un outil. Comme tous les outils, lorsqu'ils sont utilisés correctement, ils fonctionnent assez bien. Lorsqu'il est utilisé de manière inappropriée, il a besoin d'un plus grand marteau et d'un ruban adhésif.
Dans le cas du projet actuel sur lequel je travaille, il sera maintenu par des non-développeurs (ingénieurs en mécanique, pour être précis) et doit donc être simple et facile à comprendre. Il faudra plusieurs années avant que ce groupe ne dispose d'un budget pour embaucher des développeurs (en supposant que le prochain président ne supprime pas l'agence impliquée), les futures capacités de maintenance sont donc un facteur majeur dans nos réflexions.