Pourquoi devriez-vous utiliser un ORM? [fermé]

113

Si vous deviez motiver les «pros» des raisons pour lesquelles vous utiliseriez un ORM pour la direction / le client, quelles en seraient les raisons?

Essayez de garder une raison par réponse afin que nous puissions voir ce qui est voté comme les meilleures raisons

database orm Simon Munro
la source
3
vous devriez en faire un wiki si vous voulez un sondage
frankodwyer
+1 pour en avoir fait un wiki si vous voulez un sondage
cletus
16
Et les con?
Brian Matthews
4
Et pas de cuillère non plus. Non, vraiment, il y a un inconvénient: la performance. Il est beaucoup plus facile d'optimiser les requêtes DB lorsque vous n'avez pas à passer par l'ORM. (Je ne me plains pas - ayant récemment basculé vers ORM, j'en suis surtout satisfait; à des fins générales, ORM est la voie à suivre; mais gardez un moyen d'exécuter des requêtes plus près du métal si vous avez besoin de la performance)
Piskvor a quitté le bâtiment le
2
@ UğurGümüşhan, à mon humble avis, le principal avantage de l'utilisation d'un ORM est de rendre les développeurs plus productifs, en leur permettant de programmer dans le même langage et le même paradigme OO qu'ils utilisent dans le reste de leur application. Les procédures stockées ne peuvent pas fournir cela, lorsqu'elles créent le code de développeur dans le langage de procédure stockée du SGBDR. Ils ne peuvent donc pas faire tout ce qu'un ORM peut.
Bill Karwin

Réponses:

53

Rendre l'accès aux données plus abstrait et portable. Les classes d'implémentation ORM savent comment écrire du SQL spécifique au fournisseur, vous n'avez donc pas à le faire.

Bill Karwin
la source
61
Bien que je convienne qu'il s'agit d'une fonctionnalité des ORM, je proposerais que le cas d'utilisation soit assez limité. Je n'ai jamais vraiment utilisé autre chose que MySql et sqlite depuis une dizaine d'années. Je pense que c'est probablement une exigence très rare pour la plupart des développeurs.
troelskn
40
@troelskn: Je suis d'accord, j'ai utilisé de nombreux produits SGBDR, mais jamais plus d'un ou deux par projet. La portabilité n'est donc pas la valeur la plus pratique de l'abstraction de SQL. Je pense que de nombreux utilisateurs ORM veulent simplement éviter le codage en SQL.
Bill Karwin
2
les vendeurs proposent de nouvelles versions / fonctionnalités tout le temps ... ont juste besoin de gens sympas pour écrire le dialecte et une mise à jour facile c'est!
dotjoe
5
Réponse inutile typique Je me demande pourquoi elle est marquée comme bonne réponse semble que le gars qui pose la question essaie simplement de justifier à son patron qu'il devrait utiliser un ORM :) Ma question serait plutôt de savoir quel type de problème vous rencontrerez avec Hibernate stackoverflow.com/questions/6477170/…
user310291
2
@ user310291: L'OP n'a pas demandé de problèmes ou de pièges, il a demandé les avantages de l'utilisation d'un ORM. Bien sûr, il y a des avantages et des inconvénients, mais il a demandé les avantages. Franchement, je suis surpris que cette réponse ait été acceptée et ait obtenu autant de votes positifs qu'elle l'a fait, car je ne la considérerais pas comme le principal avantage d'un ORM.
Bill Karwin
83

La raison la plus importante d'utiliser un ORM est que vous puissiez avoir un modèle commercial riche et orienté objet tout en étant capable de le stocker et d'écrire rapidement des requêtes efficaces sur une base de données relationnelle. De mon point de vue, je ne vois aucun avantage réel qu'un bon ORM vous offre par rapport à d'autres DAL générés autres que les types avancés de requêtes que vous pouvez écrire.

Un type de requête auquel je pense est une requête polymorphe. Une simple requête ORM peut sélectionner toutes les formes de votre base de données. Vous récupérez une collection de formes. Mais chaque instance est un carré, un cercle ou un rectangle selon son discriminateur.

Un autre type de requête serait celui qui récupère avec empressement un objet et un ou plusieurs objets ou collections associés en un seul appel de base de données. Par exemple, chaque objet de forme est renvoyé avec ses collections de sommets et de côtés remplies.

Je suis désolé de ne pas être d'accord avec tant d'autres ici, mais je ne pense pas que la génération de code soit une raison suffisante en soi pour aller avec un ORM. Vous pouvez écrire ou trouver de nombreux bons modèles DAL pour les générateurs de code qui n'ont pas la surcharge conceptuelle ou de performances que font les ORM.

Ou, si vous pensez que vous n'avez pas besoin de savoir comment écrire du bon SQL pour utiliser un ORM, encore une fois, je ne suis pas d'accord. Il est peut-être vrai que du point de vue de l'écriture de requêtes uniques, il est plus facile de s'appuyer sur un ORM. Mais, avec les ORM, il est beaucoup trop facile de créer des routines peu performantes lorsque les développeurs ne comprennent pas comment leurs requêtes fonctionnent avec l'ORM et le SQL dans lequel elles se traduisent.

Avoir une couche de données qui fonctionne avec plusieurs bases de données peut être un avantage. Ce n'est cependant pas une question sur laquelle j'ai dû compter souvent.

En fin de compte, je dois répéter que d'après mon expérience, si vous n'utilisez pas les fonctionnalités de requête plus avancées de votre ORM, il existe d'autres options qui résolvent les problèmes restants avec moins d'apprentissage et moins de cycles de processeur.

Oh oui, certains développeurs trouvent que travailler avec les ORM est amusant, donc les ORM sont également bons du point de vue de la satisfaction des développeurs. =)

Mandrin
la source
1
Bien dit. Alors que l'affiche originale recherchait spécifiquement des «avantages» et non des «inconvénients», j'ai vu un HORRIBLE SQL créé en ne comprenant pas les impacts de la façon dont vous utilisez ORM. Pour moi, le plus grand avantage est pour les transactions CRUD simples qui constituent la majorité de votre code DAL pour les systèmes transactionnels.Je pense que vous partagez les cheveux entre ORM pur et d'autres méthodes DAL générées. Je pense que tout ce qui vous aide à traduire entre les objets et la base de données pourrait être considéré comme ORM, c'est juste un modèle opérationnel différent.
Doug Lampe
1
@Doug - Je pense que la distinction que je recherchais était qu'un simple DAL se composait d'un peu plus que du CRUD SQL généré alors qu'un ORM contenait beaucoup plus d'abstractions telles que les propriétés de navigation, la persistance des collections, les langages de requête dédiés, les caches, etc. - Une meilleure façon Si j'énonce mon point à la lumière de votre observation, s'il est vrai que l'utilisation de plus de fonctionnalités d'un ORM vous permet de mettre en œuvre plus rapidement, il n'est en aucun cas acceptable de rester ignorant du fonctionnement de ces fonctionnalités. Peut-être parce que les abstractions des ORM fuient plus que la plupart. ( En.wikipedia.org/wiki/Leaky_abstraction )
Chuck
veuillez développer un peu plus ceci: "si vous n'utilisez pas les fonctionnalités de requête plus avancées de votre ORM, il existe d'autres options qui résolvent les problèmes restants". aussi, comme le dit le créateur de hibernate gavin king: "En effet, les systèmes comme Hibernate sont intentionnellement conçus comme des" abstractions qui fuient "de sorte qu'il est possible de mélanger facilement en SQL natif si nécessaire. La fuite de l'abstraction ORM est une fonctionnalité, pas un bogue ! " - reddit.com/r/programming/comments/2cnw8x/…
jungle_mole
1) C'est vieux. À l'époque, les ORM avaient toutes les fonctionnalités (caches, requêtes, traitement par lots, etc.). À mon humble avis, les requêtes polymorphes basées sur des objets étaient la seule fonctionnalité ORM que le code gen (cartographie ADO explicite) ne pouvait pas facilement fournir. 2) Bien que certains trous utiles aient été intentionnellement laissés, il y avait aussi des maux nécessaires et des fonctionnalités avancées qui ont créé une courbe d'apprentissage élevée dans les ORM. Donc, ma réponse a été d'utiliser le code gen au lieu des ORM, sauf si vous avez besoin de requêtes avancées. *) À l'heure actuelle, il y a suffisamment de variété dans les ORM pour que le bon ensemble de fonctionnalités pour votre équipe soit probablement disponible. Mon équipe aime maintenant Linq2DB.
Chuck
60

Accélération du développement. Par exemple, éliminer le code répétitif comme le mappage des champs de résultat de requête sur les membres d'objet et vice-versa.

Bill Karwin
la source
3
Le code répétitif est très mauvais, mais ne pourriez-vous pas construire une abstraction qui supprimerait cela? Par exemple, vous pouvez avoir un objet de résultats de table / requête qui vous redonnera des lignes avec lesquelles vous pourrez ensuite faire des choses. Les ORM semblent diviser les lignes en instances de classe individuelles, plutôt que d'entrer dans l'abstraction choisie par la base de données, qui est des tables / lignes de résultats de requête. Je ne dis pas que cela signifie que les ORM ne sont pas bons, mais je ne suis pas sûr que ce soit à lui seul une raison pour les utiliser.
Benjohn
@Benjohn, je suis d'accord que la solution ORM traite les lignes individuelles comme des objets, alors que le SGBDR traite les ensembles de lignes comme une entité. Il y a des choses que vous pouvez faire dans l'état d'esprit du SGBDR que vous ne pouvez pas faire dans un état d'esprit OO.
Bill Karwin
C'est comme acheter une voiture entière juste pour utiliser le coffre, il existe de nombreuses façons d'éviter les travaux répétitifs
mohas
15

Prise en charge de l'encapsulation OO des règles métier dans votre couche d'accès aux données. Vous pouvez écrire (et déboguer) des règles métier dans la langue de préférence de votre application, au lieu de langages de déclencheurs et de procédures stockées maladroits.

Bill Karwin
la source
Mais vous ne souhaitez pas que vos règles métier soient dans la base de données? C'est l'un des avantages d'une base de données, à droite: plusieurs clients peuvent utiliser la même interface fournie par le SGBD. Si une grande partie de votre logique d'interface est verrouillée dans le code ORM d'un client particulier, elle n'est pas dans la base de données et d'autres clients ne l'utilisent pas. Cue les pauses du back-office du front-office (un modèle de client se démarque de celui d'un autre).
Benjohn
1
@Benjohn, j'ai tendance à mettre simplement des règles métier dans la base de données, mais des règles plus complexes ne sont pas facilement formées dans des contraintes déclaratives. Par exemple, "le client obtient 10% de réduction sur toute sa commande la première fois qu'il achète plus de trois paires de pantalons de la même marque." Comment mettriez-vous cette règle métier dans la base de données (gardez à l'esprit qu'une réponse impliquant des procédures stockées est maladroite).
Bill Karwin
Nous sommes en 2020, je ne vois plus personne utiliser des procédures stockées. Alors, est-ce que vous pointez toujours?
ospider
Je pense que mon point est que les gens n'utilisent pas de procédures stockées, ils utilisent le code d'application. Avez-vous compris quelque chose de différent?
Bill Karwin
10

Génération de code standard pour les opérations CRUD de base. Certains frameworks ORM peuvent inspecter directement les métadonnées de la base de données, lire les fichiers de mappage de métadonnées ou utiliser des propriétés de classe déclaratives.

Bill Karwin
la source
1
karwin.blogspot.com/2009/01/why-should-you-use-orm.html
Andrew Breksa
8

Vous pouvez facilement passer à un logiciel de base de données différent, car vous développez une abstraction.

Matt Fénelon
la source
41
En plus de 30 ans de travail sur la base de données, je n'ai pas eu à le faire une seule fois.
HLGEM
4
Cela ne veut pas dire que ce n'est pas possible! :)
Matt Fenelon
2
@HLGEM cela signifie que vous fermez les choix pour le client. Cela pourrait effectivement arriver, en seulement 3 ans de travail sur les applications Web, nous avons construit un logiciel portable utilisant des ORM
Alfabravo
1
Vous pouvez le trouver utile au cas où vous voudriez exécuter des tests sur une base de données en mémoire
Carlos Parraga
Il est possible que plusieurs instances du même logiciel utilisent des bases de données différentes. Mais en réalité, le transfert de données existantes d'un logiciel de base de données à un autre se produit rarement. Et quand c'est le cas, de nombreux ORM ne vous aident pas réellement.
jlh
4

Pour que votre modèle objet et votre modèle de persistance correspondent.

cletus
la source
1
Peut-être pour que votre persistance soit transparente à votre modèle d'objet
S.Lott
4

Le bonheur du développement, l'OMI. ORM fait abstraction de beaucoup de choses que vous devez faire dans SQL. Cela simplifie votre base de code: moins de fichiers source à gérer et les changements de schéma ne nécessitent pas des heures d'entretien.

J'utilise actuellement un ORM et cela a accéléré mon développement.

curieux
la source
3

Pour minimiser la duplication de requêtes SQL simples.

Tim Wardle
la source
3

La raison pour laquelle je me penche dessus est d'éviter le code généré par les outils DAL de VS2005 (mappage de schéma, TableAdapters).

Le DAL / BLL que j'ai créé il y a plus d'un an fonctionnait bien (pour ce pour quoi je l'avais construit) jusqu'à ce que quelqu'un d'autre commence à l'utiliser pour profiter de certaines des fonctions générées (dont je ne savais pas qu'elles étaient là)

Il semble que cela fournira une solution beaucoup plus intuitive et plus propre que la solution DAL / BLL de http://wwww.asp.net

Je pensais créer mon propre générateur de code SQL Command C # DAL, mais l'ORM ressemble à une solution plus élégante

Dan McClain
la source
2

Compilation et test des requêtes.

À mesure que les outils des ORM s'améliorent, il est plus facile de déterminer l'exactitude de vos requêtes plus rapidement grâce à des erreurs de compilation et des tests.

La compilation de vos requêtes aide les développeurs à trouver les erreurs plus rapidement. Droite? Droite. Cette compilation est rendue possible car les développeurs écrivent désormais des requêtes dans le code en utilisant leurs objets ou modèles métier au lieu de simplement des chaînes d'instructions de type SQL ou SQL.

Si vous utilisez les modèles d'accès aux données corrects dans .NET, il est facile de tester l'unité de votre logique de requête dans les collections de mémoire. Cela accélère l'exécution de vos tests car vous n'avez pas besoin d'accéder à la base de données, de configurer des données dans la base de données ou même de créer un contexte de données complet. [EDIT] Ce n'est pas aussi vrai que je le pensais en tant qu'unité les tests en mémoire peuvent présenter des défis difficiles à surmonter. Mais je trouve toujours ces tests d'intégration plus faciles à écrire que les années précédentes. [/ EDIT]

C'est certainement plus pertinent aujourd'hui qu'il y a quelques années lorsque la question a été posée, mais cela ne peut être le cas que pour Visual Studio et Entity Framework où se trouve mon expérience. Plugin votre propre environnement si possible.

Chuck
la source
1

Abstenez-vous le SQL 95% du temps, donc tout le monde dans l'équipe n'a pas besoin de savoir comment écrire des requêtes spécifiques à une base de données très efficaces.

Jared
la source
1

Je pense qu'il y a beaucoup de bons points ici (portabilité, facilité de développement / maintenance, concentration sur la modélisation métier OO, etc.), mais lorsque vous essayez de convaincre votre client ou votre direction, tout se résume à combien d'argent vous économiserez en utilisant un ORM .

Faites des estimations pour des tâches typiques (ou même des projets plus importants qui pourraient être à venir) et vous obtiendrez (espérons-le!) Quelques arguments pour le changement qui sont difficiles à ignorer.

Anders Fjeldstad
la source
0

Niveaux .net utilisant des modèles de code smith

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Pourquoi coder quelque chose qui peut être généré aussi bien.

Jobo
la source
Pouah. Nous avons utilisé Net Tiers sur un grand projet commercial et je vous déconseille vivement de l'utiliser. Le problème est qu'il n'est pas composable. Vous voulez interroger les objets Foo et Bar? Vous ne pouvez pas écrire de jointures, vous devez émettre des requêtes distinctes pour chaque type d'objet souhaité. Cela entraîne de nombreux appels à la base de données, ce qui peut compromettre les performances et l'atomicité. Mauvais mauvais mauvais. Reste loin.
Judah Gabriel Himango
0

Convainquez-les du temps / argent que vous économiserez lorsque des changements seront apportés et vous n'avez pas à réécrire votre SQL puisque l'outil ORM le fera pour vous

zmf
la source
0

Je pense qu'un inconvénient est que l'ORM aura besoin d'une mise à jour dans votre POJO. principalement lié au schéma, à la relation et à la requête. Ainsi, le scénario dans lequel vous n'êtes pas supposé apporter des modifications aux objets de modèle peut être dû au fait qu'il est partagé entre d'autres sur le projet ou le client et le serveur en noir et blanc. dans de tels cas, vous devrez le diviser en deux niveaux, ce qui nécessitera des efforts supplémentaires.

Je suis un développeur Android et comme vous le savez, les applications mobiles ne sont généralement pas de taille énorme, donc cet effort supplémentaire pour séparer le modèle pur et le modèle affecté par l'ORM ne semble pas valoir la peine.

Je comprends que cette question est générique. mais les applications mobiles sont également incluses dans un parapluie générique.

Shailendra Singh Rajawat
la source