Quels sont les avantages de l'utilisation de l'abstraction de base de données par ORM? [fermé]


19

Je commence à utiliser l'ORM recommandé par le cadre que je choisis, et bien que j'aime l'idée de la couche supplémentaire d'abstraction fournie par l'ORM, je commence à réaliser ce que cela signifie vraiment. Cela signifie que je ne travaille plus avec ma base de données (mysql) et que toutes les fonctionnalités spécifiques à mysql ont disparu, par la fenêtre, comme si elles n'existaient pas.

L'idée de l'ORM est qu'il essaie de m'aider en rendant toute base de données agnostique. Cela semble génial, mais il y a souvent une raison pour laquelle je choisis un système de base de données spécifique. Mais en empruntant la route indépendante de la base de données, l'ORM prend le plus petit dénominateur commun, ce qui signifie que je me retrouve avec le plus petit ensemble de fonctionnalités (celles prises en charge par toutes les bases de données).

Et si je sais qu'à long terme, je ne changerai pas de base de données sous-jacente? Pourquoi ne pas également accéder aux fonctionnalités spécifiques à la base de données?


2
+1: Très intéressant. J'ai généralement été un partisan des ORM, mais j'ai généralement considéré l'égalité des SGBDR (que j'ai récemment commencé à voir comme erronée).
Steven Evers

Il semble que vous souhaitiez simplement confirmer votre propre opinion; un blog pourrait vous convenir mieux qu'un site de questions / réponses.

Vous ne devriez probablement pas avoir besoin de plus que ce que l'ORM fournit. Vous voulez simplement stocker vos données d'objet dans une base de données et c'est ce que l'ORM fera. Vous ne devriez avoir besoin d'aucune autre «fonctionnalité».
CJ7

Réponses:


14

Je le vois de la même manière. Toute abstraction qui ne vous permet pas de passer en dessous lorsque cela est nécessaire est maléfique, car elle conduit à toutes sortes de vilaines inversions d'abstraction dans votre code.

Au travail, nous avons un ORM local qui fonctionne assez bien, mais pour les moments où nous avons besoin de quelque chose que ses fonctionnalités ne fournissent pas explicitement, il existe une méthode qui prend une chaîne et la dépose directement dans la requête qu'elle génère, permettant pour l'utilisation de SQL brut quand cela est nécessaire.

IMO tout ORM qui n'a pas cette fonctionnalité ne vaut pas les bits à partir desquels il est compilé.


drops it directly into the query it's generatingÇa semble intéressant. Savez-vous combien de temps il vous a fallu pour écrire cet ORM local? J'aimerais voir quelque chose comme ça dans l'un des ORM open source.
jblue

+1. Travailler avec l'aspect le plus important de mon application (les données) est la dernière chose à laquelle j'aimerais résumer et perdre la connexion.
Fosco

1
J'aime pouvoir plonger sous quand cela est nécessaire, tant que ce sous-sol implique de franchir une clôture métaphorique: "Voici des dragons. Surveillez votre pas."
Frank Shearar

1
@Jblue: Aucune idée. Tout a été écrit il y a des années, bien avant mon embauche. Ils ont mis en place un ORM avant que quiconque n'utilise le terme. Il est généralement simplement appelé "le modèle d'objet" dans notre base de code.
Mason Wheeler

3
Je suis d'accord. Pour les trucs de base et habituels, les ORM sont très utiles. Mais parfois, vous devez aller un peu plus loin, et si l'ORM ne donne pas cette capacité, c'est une autre source de problèmes pour vous.
Nikos Steiakakis

14

l'ORM prend le plus petit dénominateur commun

Je dois être en désaccord avec votre déclaration. Je prendrai nHibernate comme exemple. Ce cadre prend en charge de nombreuses bases de données, y compris les plus populaires, quelle que soit la version (et les fonctionnalités prises en charge), tout comme la plupart des ORM.

Remarque rapide: vous ne mentionnez que l'abstraction de la base de données. C'est l'un des nombreux avantages, mais je pense vraiment que les fonctionnalités orientées objet sont plus puissantes (par exemple: l'héritage). Et You design your domain model first...

... Revenons à l'abstraction. Ce n'est pas le plus petit dénominateur commun. Dans nHibernate , vous avez des dialectes. Il vous permet d'utiliser un même code pour interroger différentes bases de données. Les dialectes s'occupent de la gestion des fonctionnalités pour vous. La bonne déclaration est la suivante a given dialect will try to use all the power of a given database system.

Par exemple, prenons le SqlServer2005dialecte qui, lors de son introduction, tirait parti des nouvelles fonctionnalités de pagination de SQL Server 2005. Utiliser ce dialecte au lieu de SqlServer2000simplement augmenter vos performances.

Bien sûr, il existe des exceptions, mais je n'en ai rencontré aucune depuis de nombreuses années de travail avec nHibernate, et mes applications sont très centrées sur les données.


+1 pour avoir préconisé NHibernate. Peu de courbe d'apprentissage par rapport aux autres ORM, mais l'effort en vaut la peine.
richeym

1
J'aimerais entendre des DBA à ce sujet. Lors de mon dernier emploi, Hibernate n'était rien d'autre qu'un problème (le SQL qu'il a généré était absolument dégoûtant.)
Fosco

+1 pour ce commentaire. C'est parfait. Lorsque vous commencez à comparer la puissance d'un bon ORM comme nHibernate (avec mise en cache, chargement différé, etc.), vous voyez pourquoi cette abstraction est bonne et pourquoi vos besoins spécifiques à la base de données sont moins importants.
Chris Holmes du

1
Fosco, donne à nHibernate une autre chance. Comme tout autre technoloy, vous devez comprendre ce qui se passe à l'intérieur, pour l'utiliser correctement.

+1, ORM est une intersection maximale de ce que Java peut faire avec ce qu'un pilote JDBC particulier peut faire. Vous êtes libre de choisir le montant des investissements que vous souhaitez faire dans la couche de persistance de votre application
bobah

5

L'idée est géniale, mais je n'ai jamais été déplacé au point d'utiliser un outil ORM. Ce n'est tout simplement pas un problème pour moi d'écrire le SQL moi-même (ou de gérer le stockage utilisé). Mais, j'ai le luxe de travailler sur un plus petit nombre de projets avec une durée de vie plus longue du produit, donc une fois que la manipulation SQL et DB codée à la main est en place, elle est en place. De plus, vous pouvez évidemment gérer toutes les requêtes SQL directes dont vous avez besoin sans avoir à adapter votre processus à la façon de penser de l'outil ORM.

Donc, je suppose que les questions devraient être avant de vous lancer dans une:

Gagnez-vous réellement quelque chose en les utilisant? Autrement dit, économisez-vous suffisamment d'efforts en implémentant un outil ORM pour le rendre utile et pour qu'il vaille la peine d'ajouter une complication supplémentaire à votre système? (Cela est particulièrement vrai pour les applications commerciales, où cette `` pièce '' supplémentaire est maintenant un vecteur supplémentaire pour les problèmes de support potentiels)

Et puis, la couche d'abstraction supplémentaire aura-t-elle un impact négatif sur l'application? Est-ce que ça va être plus lent que le code SQL codé à la main, etc.


5

O / RM a été critiqué régulièrement. Ted Neward l'appelait le " Vietnam de l'informatique " il y a quelques années. O / RM

démarre bien, devient plus compliqué avec le temps et emprisonne bientôt ses utilisateurs dans un engagement sans point de démarcation clair, sans conditions de victoire claires et sans stratégie de sortie claire.

Sauf si vous écrivez simplement votre propre mappage ad hoc (ce qui est une bonne solution dans de nombreux cas, comme d'autres l'ont déjà dit), vous pouvez envisager des alternatives telles que l'utilisation d'une base de données non relationnelle. Certains disent qu'une base de données vraiment objet est meilleure, d'autres mots à la mode mentionnés dans ce contexte sont LINQ, Ruby et Tutorial D.Je suppose que, contrairement aux bases de données vraiment relationnelles, il y a vraiment des bases de données objet. Mais dans la pratique, j'ai trouvé que la modélisation des données conceptuelles - c'est-à-dire pour savoir quels objets du monde réel vous souhaitez stocker des données et comment ces objets sont liés les uns aux autres - est plus importante que de savoir comment exprimer votre modèle conceptuel dans n'importe quel langage de programmation ou de base de données.


2
Bonne lecture là-bas. J'ai bouclé la boucle dans ma carrière et j'ai ré-embrassé le modèle relationnel avec un succès complet.
Jé Queue

2
+1 @Xepoch - J'ai récemment entendu parler de face re: ORMs - pourquoi SQL est-il laissé de côté? Abstraction, bien sûr - mais ORM semble favoriser la phobie SQL.
sunwukung

1
@sunwukung, je n'étais pas toujours d'accord, mais je crois maintenant que SQL devrait être considéré comme une couche logique de première classe, et pas seulement quelque chose qui est utilisé comme protocole filaire.
Jé Queue

3

Quelle est l'alternative?

C'est une notion intéressante. En faisant abstraction des fonctionnalités de la base de données sous-jacente, nous perdons définitivement certaines des fonctionnalités de l'implémentation de la base de données spécifique. (Que nous devions ou non dépendre de fonctionnalités de base de données spécifiques est un autre argument) Je suppose que cela pourrait être résolu par des ORM spécifiques à la base de données qui vous permettent d'accéder aux fonctionnalités spécifiques, mais cela pourrait être plus difficile que cela en vaut la peine et une étape dans la mauvaise direction.

À la fin de la journée, vous devez vous demander - quelle est l'alternative?

Devrions-nous cesser d'utiliser les ORM et recommencer à écrire tous les accès à la base de données nous-mêmes? Bien sûr, nous pourrions perdre l'accès à quelques fonctionnalités de base de données via l'ORM, mais vous pouvez toujours accéder à celles qui utilisent des techniques old-school. Au final, les gains de productivité que vous obtenez l'emportent totalement sur les inconvénients.


Je remettrais en question la nécessité d'utiliser une base de données rationnelle. Cela me dérange que les gens passent immédiatement aux SGBDR même s'ils ne sont pas la bonne solution. Les bases de données d'objets, par exemple, fournissent une solution très élégante à de nombreux problèmes. Sont-ils parfaits? Non, mais les gens prennent rarement la peine de les évaluer. Il y a une tendance inquiétante: "J'ai besoin de stocker des données, je vais utiliser SQL!"
Matt Olenik

6
@Matt: Les SGBDR sont des technologies très éprouvées et éprouvées et bien comprises. Il y a des tonnes de gens qui ont de l'expérience avec eux et un grand nombre d'outils tiers. Du point de vue de l'entreprise, il y a beaucoup de valeur à cela lorsque vous traitez quelque chose de très précieux comme vos données. Sur les petits projets, il est toujours utile de pouvoir démarrer un projet (comme un service Web LAMP) et d'avoir la plupart des logiciels là et bien documentés.
David Thornley

3

Un ORM équivaut essentiellement à des « procédures non stockées ». Là, j'ai inventé un terme.

Tout ce qu'un ORM fait, vous pouvez le répliquer avec des vues, des déclencheurs et des procédures stockées. Ils aident à extraire le SQL brut et peuvent garder les bases de données normalisées cohérentes. Mais cela ne fonctionne bien que pour les cas simples. S'il y a trop de données mach pour les traiter, elles peuvent devenir un drain de performance. (Les ORM en PHP prennent souvent le côté script de données, car les chaînes du générateur SQL ne peuvent pas tout résumer.)

Mais comme d'habitude, tout dépend de l'application et de la tâche à accomplir.


2
"Procédures non stockées" - le terme approprié est "SQL paramétré". Vous ne faites qu'effleurer la surface de ce qu'un ORM mature peut faire pour vous (par lots, chargement paresseux, etc.)
richeym

@richeym: La plupart des ORM en PHP n'utilisent pas d'instructions préparées, ni d'espaces réservés paramétrés. C'est l'échappement SQL et la concaténation tout au long. Bien sûr, ils offrent des avantages de niveau supérieur par rapport aux requêtes SQL manuelles fastidieuses. Sémentiquement, cependant, ils retirent la logique de traitement de la base de données, d'où des "procédures non stockées".
mario

3

Une chose qui nuit à l'utilisation des ORM est que beaucoup de leurs fans ont tendance à affirmer que nous n'avons plus besoin de connaître la théorie SQL et RDB. Les résultats varient de drôles à tout à fait catastrophiques. Et ceci malgré le million de fois où ORM 'fabrique et déclare que nous devons bien connaître la théorie SQL et RDB pour utiliser et configurer correctement un ORM.

Pourquoi les gens prennent un outil qui a ses utilisations dans de nombreux contextes, mais pas tous, dans une solution miracle magique et universellement applicable, cela me dépasse.


1

L'année dernière, j'ai travaillé sur une application interne qui changeait fréquemment, et j'étais très heureux que nous ayons utilisé un ORM. L'application était une application de soutien pour une équipe de gestion du changement, et au fur et à mesure que le projet plus vaste évoluait, notre petite application a obtenu de nouvelles exigences pour des situations qui n'existaient pas et ne pouvaient pas être prévues quelques mois auparavant.

Grâce à l'ORM ( Propel , en PHP), nous avons divisé une partie de la logique du code, donc une fonction a ajouté la partie "est valide pour l'enregistrement" de la requête, une autre la partie de sécurité ("n'affiche ces enregistrements que si l'utilisateur a ces capacités "), ... Si la structure sous-jacente changeait (un champ supplémentaire qui devait être pris en considération pour la" validité des enregistrements "), nous n'avions qu'à changer une fonction, pas vingt clauses SQL.

Nous venions d'une situation où toutes (enfin, la plupart) des clauses SQL étaient stockées dans un fichier XML séparé, donc "les modifications de la base de données seraient faciles à gérer". Croyez-moi, ils ne l'étaient pas. Une partie était si horrible que j'ai dû la soumettre au Daily WTF .

Si une requête était trop compliquée à exprimer avec Propel Criteria, ou si nous avions besoin de fonctionnalités spécifiques au fournisseur (principalement la recherche en texte intégral, car nous utilisions MySQL), ce n'était pas un problème avec Propel. Vous pouvez ajouter des critères personnalisés , ou lorsque vous en avez vraiment besoin, nous avons utilisé du SQL brut ( maintenant encore plus facile à combiner avec des objets Propel réels). Vous pouvez facilement ajouter vos modules complémentaires spécifiques au fournisseur aux classes générées, afin d'avoir le meilleur des deux mondes: pas de SQL dans votre code d'application, mais avec toutes les capacités de votre moteur de base de données.


1

Mais le fait est que vous pouvez programmer loin de la base de données, ce qui signifie que vous n'avez pas besoin de penser comme si vous étiez dans la base de données.

Je travaille en C # maintenant et j'utilise beaucoup LINQ, donc beaucoup, beaucoup de méthodes fluides. Je n'ai pas besoin de penser à la façon dont mes objets sont stockés ou trouvés, ou même enregistrés au niveau du programme, et très peu au niveau de la couche métier.

Très souvent, les méthodes fournies par les bases de données spécifiques elles-mêmes sont utilisées dans le connecteur DB, de sorte que vous obtenez ces optimisations sans avoir besoin de savoir ce qu'elles sont.

Vous pouvez toujours écrire des fonctions côté DB. Souvent, vous pouvez simplement les cartographier.

Et surtout, une telle séparation permet la testabilité et vous force (un peu) à écrire du code mieux structuré


2
Encore une fois, pourquoi avez-vous besoin de programmer en dehors de la base de données? Pourquoi ne pas faire de la base de données une partie intégrante de votre développement car vous avez choisi d'en utiliser une en premier lieu. Si vous n'aviez pas besoin d'un SGBDR, pourquoi pousser un ORM dessus?
Jé Queue

1
C'est une partie intégrante. Une base de données réussit très bien à maintenir et à renforcer les relations et à récupérer les données brutes. Cependant, les choses que vous voulez faire avec ces données ont probablement déjà été traitées dans l'encapsuleur ORM. Et en plus des éléments critiques, pourquoi retirer la logique de la couche métier?
burnt_hand

@burnt_hand - "Mais le fait est que vous pouvez programmer loin de la base de données, ce qui signifie que vous n'avez pas besoin de penser comme si vous étiez dans la base de données." Quels sont les avantages universels? Je peux le voir comme un avantage lorsque votre application recherche simplement un moyen de conserver les objets. Mais pour les données relationnelles, OLTP et autres, la programmation loin de la base de données est un moyen de vous gâcher beaucoup de temps.
luis.espinal

@ luis.espinal - qu'est-ce que ça veut dire foutre le cap? je suis vraiment curieux. Avez-vous un exemple?
burnt_hand

@burnt_hand - en fait, j'ai plusieurs exemples réels. Le plus récent implique un très grand modèle de domaine et, en termes de performances, le projet doit télécharger tous les mappages d'hibernation au démarrage. La fabrique de sessions résultante finit par consommer jusqu'à 30% de la mémoire utilisée ... juste pour les liaisons. La base de code est maintenant trop engagée avec l'ORM et il est impossible de la réécrire. Cela a maintenant des implications réelles puisque l'application approche des limites physiques du matériel qu'elle était censée exécuter. Bummer.
luis.espinal

1

Les ORM peuvent également vous donner accès à des fonctionnalités spécifiques à la base de données, cela dépend de l'ORM que vous utilisez et des fonctionnalités qu'il fournit.

Par exemple, dans le projet actuel sur lequel je travaille, nous utilisons l'API Java Persistence et Hibernate. Malgré cela, nous utilisons plusieurs fonctionnalités spécifiques à la base de données, telles que la recherche dans les tableaux avec soundex.

Pour moi, le principal avantage d'utiliser un ORM n'est pas nécessairement qu'il rend une base de données d'application agnostique (bien que ce soit également une bonne chose), mais que pour la plupart, je n'ai pas à penser à la façon dont les choses sont stockées et récupéré.

Cependant , à un moment donné, vous devrez probablement y penser de toute façon, en fonction des exigences de votre application. L'ORM n'est pas magique.


1

J'ai écrit le mien qui m'aide à faire des sélections et des insertions plus facilement.

Chaque chose spécifique à db est disponible. J'ai juste besoin d'écrire moi-même la requête avec laquelle la bibliothèque m'aide (je peux utiliser '?' Et params au lieu de nommer manuellement un paramètre et utiliser .Add)

Je suppose que la mienne est à moitié utile à moitié utile. J'obtiens de l'aide dans le monde ORM et je fais des parties importantes dans le monde des requêtes.


1

Écrire du code pour insérer et sélectionner, mettre à jour en ligne ou avec des proc stockés et les retracer via le DAL est plus la norme plutôt bénéfique que dans le cas exceptionnel. Les ORM disponibles, les bases de données de support et les langues, la question que vous devriez vous poser pourquoi n'utilisez-vous pas ORM?

Ils sont standardisés, universels, spécifiés ou génériques. en outre, sa mise en œuvre est plus rapide et plus facile. J'ai utilisé subsonic, linq-to-sql et le framework d'entité. Il permet au développeur de se concentrer sur la logique et les règles métier au lieu du mappage de la base de données.


1
Il y a beaucoup de raisons d'utiliser ou de NE PAS utiliser un ORM. Les ORM ne sont pas une panacée et très peu de gens savent réellement comment les utiliser efficacement. En outre, dans de nombreux cas, la logique métier se reflète déjà (en partie) de manière très naturelle dans les relations déjà existantes dans un SGBDR (c'est le scénario le plus courant que j'ai rencontré, passé et présent). Un RDBM bien conçu a un fondement mathématique solide, bien compris et éprouvé. Tout ne doit pas être modélisé avec un RDMB bien sûr, mais également, un ORM n'est pas non plus une solution universelle.
luis.espinal

1

Mes (simples) deux cents:

1: Il y a des ORMS et il y a des ORMS. Certains ORMS sont basés sur Active Record, d'autres sur Data Mapper - c'est en soi une considération pertinente, mais qui nécessite une enquête pour comprendre les implications. En général - mon expérience en PHP est que ORMS supporte le premier, peu le supporte. Les ORM basés sur Active Record semblent avoir l'un des deux effets suivants: ils dénormalisent la base de données ou invoquent une pléthore de classes pour prendre en charge les interactions d'objets.

2: L'avantage des ORM diminue en corrélation directe avec la complexité de la requête que vous devez exécuter. Lorsque vous avez une belle relation simple - c'est-à-dire utilisateurs -> messages, ils peuvent très bien fonctionner. C'est (OMI) que la plupart des ORM / frameworks utilisent des exemples comme celui-ci. Cependant, lorsque vous devez exécuter des requêtes complexes, la quantité d'ORMQL que vous devez générer est comparable à la longueur de chaîne d'une requête SQL régulière - mais moins performante en raison du graphique d'objet exécutant l'appel de la requête, ce qui vainc le point de départ. abstraction. Donc, en un mot - les ORM sont brillants pour les premiers 30 à 50% de vos tâches de base de données - mais terribles pour le dernier. Je pense que c'est une autre raison pour laquelle la RA est si répandue.

3: Pourquoi se cacher de la base de données? Souhaitez-vous utiliser un langage côté serveur pour résumer javascript?

Personnellement, je mélange ces approches:

  • utiliser ORM pour les bases, en chargeant les "utilisateurs"
  • utiliser un DAO contenant plusieurs requêtes SQL précuites (ie selectLike, selectWhere).
  • étendre le DAO si nécessaire pour ajouter des requêtes personnalisées plus spécifiques mais réutilisables
  • Fournissez un accès simple à la base de données via la requête DAO - c'est-à-dire $ data = Dao-> (votre chaîne sql) pour exécuter des requêtes uniques.

Cela dit, Doctrine 2 sort bientôt, ce qui semble vraiment intéressant.


0

Vous pouvez utiliser des frameworks de mappage SQL comme myBatis si vous souhaitez utiliser les fonctionnalités SQL.


Ce n'est pas vraiment une réponse à la question de jblue sur les avantages d'utiliser un tel mappeur
Lukas Eder
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.