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

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?

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

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.

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.

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.

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.

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.

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.

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.

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é

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.

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.

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

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.

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