Quels sont les avantages de l'utilisation d'un ORM? [fermé]

Les ORM sont hype pour être la solution aux problèmes d'accès aux données. Personnellement, après l'avoir utilisé dans un Projet d'Entreprise, ils sont loin d'être la solution pour le Développement d'Applications d'Entreprise. Peut-être qu'ils travaillent dans de petits projets. Voici les problèmes que nous avons rencontrés avec eux spécifiquement nHibernate:

1. Configuration: les technologies ORM nécessitent des fichiers de configuration pour mapper les schémas de table en structures d'objets. Dans les grands systèmes d'entreprise la configuration se développe très rapidement et devient extrêmement difficile à créer et à gérer. La maintenance de la configuration devient également fastidieuse et irrécupérable, car les exigences et les modèles métier changent et évoluent constamment dans un environnement agile.

2. Requêtes personnalisées: la possibilité de mapper des requêtes personnalisées qui ne correspondent à aucun objet défini n'est pas prise en charge ou n'est pas recommandée par les fournisseurs d'Infrastructure. Les développeurs sont obligés de trouver des solutions de contournement en écrivant des objets et des requêtes adhoc, ou écriture de code personnalisé pour obtenir les données dont ils ont besoin. Ils peuvent avoir à utiliser des procédures stockées sur une base régulière pour quelque chose de plus complexe qu'un simple Select.

3. Proprietery binding: ces frameworks nécessitent l'utilisation de bibliothèques propriétaires et de langages de requête d'objet propriétaires qui ne sont pas standardisés dans l'industrie de l'informatique. Ces bibliothèques propriétaires et langages de requête lient l'application à l'implémentation spécifique du fournisseur avec peu ou pas de flexibilité changer si nécessaire et pas d'interopérabilité pour collaborer les uns avec les autres.

4. Langages de requête D'objet: de nouveaux langages de requête appelés langages de requête D'objet sont fournis pour effectuer des requêtes sur le modèle d'objet. Ils génèrent automatiquement des requêtes SQL sur la base de données et l'utilisateur est extrait du processus. Pour les développeurs orientés objet, cela peut sembler un avantage car ils estiment que le problème de L'écriture SQL est résolu. Le problème dans la pratique est que ces requêtes les langages ne peuvent pas prendre en charge certaines des constructions SQL intermédiaires à avancées requises par la plupart des applications du monde réel. Ils empêchent également les développeurs de modifier les requêtes SQL si nécessaire.

5. Performance: les couches ORM utilisent la réflexion et l'introspection pour instancier et remplir les objets avec les données de la base de données. Ce sont des opérations coûteuses en termes de traitement et ajoutent à la dégradation des performances des opérations de cartographie. Les requêtes D'objet qui sont traduites pour produire des requêtes non optimisées sans la possibilité de les régler entraînant des pertes de performances importantes et une surcharge des systèmes de gestion de base de données. Le réglage des performances du SQL est presque impossible car les frameworks offrent peu de flexibilité par rapport au contrôle du SQL généré automatiquement.

6. Couplage serré: cette approche crée une dépendance étroite entre les objets du modèle et les schémas de base de données. Les développeurs ne veulent pas d'une corrélation un-à-un entre les champs de base de données et champs de la classe. La modification du schéma de base de données a des effets d'ondulation dans le modèle d'objet et la configuration de mappage et vice versa.

7. Caches: cette approche nécessite également l'utilisation de caches d'objets et de contextes nécessaires pour maintenir et suivre l'état de l'objet et réduire les allers-retours de la base de données pour les données mises en cache. Ces caches s'ils ne sont pas maintenus et synchronisés dans une implémentation à plusieurs niveaux peuvent avoir des ramifications importantes en termes de précision des données et de concurrence. Souvent, des caches tiers ou des caches externes doivent être branchés pour résoudre ce problème, ce qui ajoute une charge importante à la couche d'accès aux données.

Pour plus d'informations sur notre analyse, vous pouvez lire: http://www.orasissoftware.com/driver.aspx?topic=whitepaper

À un niveau très élevé: les ORM aident à réduire l'incompatibilité D'impédance objet-relationnelle. Ils vous permettent de stocker et de récupérer des objets vivants complets à partir d'une base de données relationnelle sans faire beaucoup d'analyse/sérialisation vous-même.

Qu'est-ce que ça me donne en tant que développeur?

Pour commencer, il vous aide à rester au sec. Soit vous schéma ou vous les classes de modèle font autorité et l'autre est généré automatiquement ce qui réduit le nombre de bugs et la quantité de Plaque de chaudière code.

Il aide à marshaling. Les ORM gèrent généralement le marshaling des valeurs des colonnes individuelles dans les types appropriés afin que vous n'ayez pas à les analyser/les sérialiser vous-même. En outre, il vous permet de récupérer un objet entièrement formé à partir de la base de données plutôt que simplement des objets de ligne que vous devez envelopper vous-même.

En quoi mon code différera-t-il des instructions SELECT individuelles que j'utilise maintenant?

Puisque vos requêtes retourneront des objets plutôt que simplement sur les lignes, vous pourrez accéder aux objets associés en utilisant l'accès aux attributs plutôt que de créer une nouvelle requête. Vous êtes généralement capable d'écrire SQL directement lorsque vous en avez besoin, mais pour la plupart des opérations (CRUD), L'ORM simplifiera le code pour interagir avec les objets persistants.

Comment cela aidera-t-il L'accès à la base de données et la sécurité?

D'une manière générale, les ORM ont leur propre API pour créer des requêtes (par exemple. accès aux attributs) et sont donc moins vulnérables aux attaques par injection SQL; cependant, ils vous permettent souvent d'injecter votre propre SQL dans les requêtes générées afin que vous puissiez faire des choses étranges si vous en avez besoin. Tel SQL injecté, vous êtes responsable de la désinfection vous-même, mais, si vous restez à l'écart de l'utilisation de ces fonctionnalités, L'ORM devrait prendre soin de la désinfection des données utilisateur automatiquement.

Comment trouve-t-il le schéma de base de données et les informations d'identification de l'utilisateur?

De nombreux ORM sont livrés avec des outils qui inspectent un schéma et construisent un ensemble de classes de modèle qui vous permettent d'interagir avec les objets dans la base de données. [Base de données] identification de l'utilisateur sont généralement stockées dans un fichier de paramètres.

Si vous écrivez votre couche d'accès aux données à la main, vous écrivez essentiellement votre propre ORM pauvre en fonctionnalités.

Oren Eini a un joli blog qui résume les fonctionnalités essentielles dont vous pourriez avoir besoin dans votre DAL / ORM et pourquoi écrire le vôtre devient une mauvaise idée Après le temps: http://ayende.com/Blog/archive/2006/05/12/25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

EDIT: L'OP a commenté dans d'autres réponses que sa base de code n'est pas très orientée objet. Traitant de l'objet le mappage n'est qu'une facette des ORM. Le modèle Active Record est un bon exemple de la façon dont les ORM sont toujours utiles dans les scénarios où les objets mappent 1: 1 aux tables.

Principaux Avantages:

1. Abstraction De Base De Données
2. mentalité de conception centrée sur L'API
3. haut niveau = = moins à craindre au niveau fondamental (il a été pensé pour vous)

Je dois dire que travailler avec un ORM est vraiment l'évolution des applications pilotées par la base de données. Vous vous inquiétez moins du SQL standard que vous écrivez toujours, et plus sur la façon dont les interfaces peuvent fonctionner ensemble pour créer un système très simple.

J'aime ne pas avoir à vous soucier de INNER JOIN et sélectionnez COUNT (*). Je travaille juste dans mon abstraction de haut niveau, et j'ai pris soin de l'abstraction de base de données en même temps.

Cela dit, Je n'ai jamais vraiment rencontré de problème où j'avais besoin d'exécuter le même code sur plus d'un système de base de données à la fois de manière réaliste. Toutefois, cela ne veut pas dire que le cas n'existe pas, c'est un problème très réel pour certains développeurs.

Je ne peux pas parler pour d'autres ORM, juste hiberner (pour Java).

Hibernate me donne ce qui suit:

• met automatiquement à jour le schéma des tables du système de production au moment de l'exécution. Parfois, vous devez toujours mettre à jour certaines choses manuellement vous-même.
• crée automatiquement des clés étrangères qui vous empêche d'écrire un mauvais code qui crée des données orphelines.
• implémente le regroupement de connexions. Plusieurs fournisseurs de regroupement de connexions sont disponibles.
• Cache Les données pour un accès plus rapide. Plusieurs fournisseurs de mise en cache sont disponibles. Cela vous permet également de regrouper plusieurs serveurs pour vous aider à échelle.
• rend l'accès à la base de données plus transparent afin que vous puissiez facilement porter votre application vers une autre base de données.
• rendre les requêtes plus faciles à écrire. La requête suivante qui vous obligerait normalement à écrire "join" trois fois peut être écrite comme ceci:
  • " de la facture i où I. client.adresse.ville = ?"cela récupère toutes les factures avec un ville spécifique
  • une liste d'objets de facture est renvoyée. Je peux alors appeler facture.getCustomer ().getCompanyName (); si les données ne sont pas déjà dans le cache, la base de données est interrogée automatiquement en arrière-plan

Vous pouvez désosser une base de données pour créer le schéma hibernate (Je ne l'ai pas essayé moi-même) ou vous pouvez créer le schéma à partir de zéro.

Il y a bien sûr une courbe d'apprentissage comme avec toute nouvelle technologie mais je pense que ça vaut bien la peine il.

Si nécessaire, vous pouvez toujours passer au niveau SQL inférieur pour écrire une requête optimisée.

La plupart des bases de données utilisées sont des bases de données relationnelles qui ne se traduisent pas directement en objets. Ce Qu'un mappeur relationnel objet fait est de prendre les données, de créer un shell autour de lui avec des fonctions utilitaires pour la mise à jour, la suppression, l'insertion et d'autres opérations qui peuvent être effectuées. Ainsi, au lieu de penser comme un tableau de lignes, vous disposez maintenant d'une liste d'objets que vous pouvez manipuler comme tout les autres et d'appeler tout simplement obj.Save() lorsque vous avez terminé.

Je vous suggère de jeter un oeil à quelques parmi les ORM utilisés, un de mes favoris est L'ORM utilisé dans le framework python, django . L'idée est que vous écrivez une définition de l'apparence de vos données dans la base de données et que L'ORM s'occupe de la validation, des vérifications et de toute mécanique à exécuter avant l'insertion des données.

Personnellement, je n'ai pas eu une grande expérience avec L'utilisation de la technologie ORM à ce jour. Je travaille actuellement pour une entreprise qui utilise nHibernate et je ne peux vraiment pas y aller. Donnez-moi un proc stocké et DAL n'importe quel jour! Plus de code sûr ... mais aussi plus de contrôle et de code plus facile à déboguer - d'après mon expérience en utilisant une première version de nHibernate, il faut l'ajouter.

Qu'est-ce que ça me donne en tant que développeur?

Vous fait gagner du temps, car vous n'avez pas besoin de coder la partie d'accès à la base de données.

En quoi mon code différera-t-il des instructions SELECT individuelles que j'utilise maintenant?

Vous utiliserez des attributs ou des fichiers xml pour définir le mappage de classe aux tables de base de données.

Comment cela va-t-il aider avec L'accès à la base de données et la sécurité?

La plupart des frameworks essaient d'adhérer aux meilleures pratiques de base de données où applicable, comme SQL paramétré et autres. Parce que le détail de l'implémentation est codé dans le framework, vous n'avez pas à vous en soucier. Pour cette raison, cependant, il est également important de comprendre le cadre que vous utilisez et d'être conscient des défauts de conception ou des bugs qui peuvent ouvrir des trous inattendus.

Comment trouve-t-il le schéma de base de données et les informations d'identification de l'utilisateur?

Vous fournissez la chaîne de connexion comme toujours. Les fournisseurs de framework (par exemple SQL, Oracle, MySQL classes spécifiques) fournissent l'implémentation qui interroge le schéma db, traite les mappages de classes et rend / exécute le code d'accès db si nécessaire.

L'utilisation d'un ORM supprimera les dépendances de votre code sur un dialecte SQL particulier. Au lieu d'interagir directement avec la base de données, vous interagirez avec une couche d'abstraction qui fournit une isolation entre votre code et l'implémentation de la base de données. De plus, les ORM fournissent généralement une protection contre L'injection SQL en construisant des requêtes paramétrées. Certes, vous pouvez le faire vous-même, mais il est agréable d'avoir la garantie du cadre.

Les ORM fonctionnent de deux façons: certains découvrent le schéma à partir d'une base de données existante-le concepteur LINQToSQL le fait -, d'autres vous demandent de mapper votre classe sur une table. Dans les deux cas, une fois que le schéma a été mappé, L'ORM peut être capable de créer (recréer) votre structure de base de données pour vous. Les autorisations DB doivent probablement encore être appliquées à la main ou via SQL personnalisé.

Généralement, les informations d'identification fournies par programme via L'API ou à l'aide d'un fichier de configuration-ou les deux, par défaut provenant d'une configuration fichier, mais capable d'être remplacé dans le code.

Pour un podcast qui traite ORM en détail, voir le lien suivant. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

Bien que je sois presque entièrement d'accord avec la réponse acceptée, je pense qu'elle peut être modifiée avec des alternatives légères à l'esprit.

• Si vous avez un SQL complexe, réglé à la main
• si vos objets n'ont pas de Relations 1:1, 1:m ou m:N avec d'autres objets
• Si vous avez un schéma hérité complexe qui ne peut pas être refactorisé

...ensuite, vous pourriez bénéficier d'un ORM léger où SQL n'est pas obscurci ou abstrait au point où il est plus facile de écrivez votre propre intégration de base de données.

Ce sont quelques-unes des nombreuses raisons pour lesquelles l'équipe de développeurs de mon entreprise a décidé que nous devions faire une abstraction plus flexible pour résider au-dessus du JDBC.

Il existe de nombreuses alternatives open source qui accomplissent des choses similaires, et jORM est notre solution proposée.

Je recommande d'évaluer quelques-uns des candidats les plus forts avant de choisir un ORM léger. Ils sont légèrement différents dans leur approche des bases de données abstraites, mais peut sembler similaire d'une vue de haut en bas.

• jORM
• ActiveJDBC
• ORMLite

Ma préoccupation avec les frameworks ORM est probablement la chose même qui le rend attrayant pour beaucoup de développeurs.

Nameley qu'il évite le besoin de "se soucier" de ce qui se passe au niveau de la base de données. La plupart des problèmes que nous voyons pendant le fonctionnement quotidien de nos applications sont liés à des problèmes de base de données. Je m'inquiète un peu d'un monde 100% ORM que les gens ne sauront pas quelles requêtes frappent la base de données, ou s'ils le font, ils ne savent pas comment les changer ou de les optimiser.

{Je me rends compte que cela peut être une réponse contraversiale :)}