Quels sont les avantages d'utiliser un ORM?
En tant que développeur Web cherchant à passer de sites codés à la main PHP sites à des sites basés sur un framework, j'ai beaucoup discuté des avantages d'un ORM par rapport à un autre. Il semble être utile pour projets d'une taille certaine (?) , et encore plus importante pour les applications de niveau entreprise.
Qu'est-ce que cela me donne en tant que développeur? En quoi mon code sera-t-il différent des instructions SELECT individuelles que j'utilise maintenant? Comment cela aidera-t-il avec l'accès et la sécurité de la base de données? Comment peut-il connaître le schéma de base de données et les informations d'identification de l'utilisateur?
Edit: @ duffymo a souligné ce qui aurait dû être évident pour moi: ORM n'est utile que pour OOP code. Mon code est pas OO, donc je n'ai pas rencontré les problèmes que ORM résout.
Je dirais que si vous ne traitez pas avec des objets, il est inutile d'utiliser un ORM.
Si vos tables/colonnes relationnelles mappent 1: 1 avec des objets/attributs, il n'y a pas grand intérêt à utiliser un ORM.
Si vos objets n'ont pas de relations 1: 1, 1: m ou m: n avec d'autres objets, il n'y a pas grand intérêt à utiliser un ORM.
Si vous avez du SQL complexe et réglé manuellement, il n'y a pas grand intérêt à utiliser un ORM.
Si vous avez décidé que votre base de données aura des procédures stockées comme interface, il n'y a pas grand intérêt à utiliser un ORM.
Si vous avez un schéma hérité complexe qui ne peut pas être refactorisé, il n'y a pas grand intérêt à utiliser un ORM.
Voici donc l'inverse:
Si vous avez un modèle d'objet solide, avec des relations entre les objets qui sont 1: 1, 1: m et m: n, ne disposez pas de procédures stockées, et comme le SQL dynamique qu'une solution ORM vous donnera, par tous les moyens utilisez un ORM.
De telles décisions sont toujours un choix. Choisir, mettre en œuvre, mesurer, évaluer.
Les ORM sont mis en avant pour être la solution aux problèmes d'accès aux données. Personnellement, après les avoir utilisés 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:
Configuration: les technologies ORM nécessitent des fichiers de configuration pour mapper les schémas de table dans les structures d'objets. Dans les grands systèmes d'entreprise, la configuration croît très rapidement et devient extrêmement difficile à créer et à gérer. La maintenance de la configuration devient également fastidieuse et irréalisable, car les exigences et les modèles métier changent et évoluent constamment dans un environnement agile.
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 de framework. Les développeurs sont obligés de trouver des solutions en écrivant des objets et des requêtes ad hoc ou en écrivant du code personnalisé pour obtenir les données dont ils ont besoin. Ils peuvent avoir à utiliser régulièrement des procédures stockées pour quelque chose de plus complexe qu'un simple Select.
Liaison de propriété: ces cadres nécessitent l'utilisation de bibliothèques propriétaires et de langages de requête d'objets propriétaires qui ne sont pas standardisés dans l'industrie informatique. Ces bibliothèques et langages de requête propriétaires lient l'application à l'implémentation spécifique du fournisseur avec peu ou pas de flexibilité pour changer si nécessaire et aucune interopérabilité pour collaborer entre eux.
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 pratique est que ces langages de requête 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.
Performances: les couches ORM utilisent la réflexion et l'introspection pour instancier et remplir les objets avec des données de la base de données. Ce sont des opérations coûteuses en termes de traitement et s'ajoutent à la dégradation des performances des opérations de mappage. Les requêtes d'objets 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é sur le contrôle du SQL qui est généré automatiquement.
Couplage étroit: 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 les champs de classe. La modification du schéma de la base de données a des effets d'ondulation dans le modèle d'objet et la configuration de mappage et vice versa.
Caches: cette approche nécessite également l'utilisation de caches d'objets et de contextes qui sont nécessaires pour maintenir et suivre l'état de l'objet et réduire les allers-retours de 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 simultanéité. Souvent, des caches tiers ou des caches externes doivent être connectés pour résoudre ce problème, ce qui alourdit considérablement 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'inadéquation de l'impédance objet-relationnelle. Ils vous permettent de stocker et de récupérer des objets en direct complets à partir d'une base de données relationnelle sans faire beaucoup d'analyse/de sérialisation vous-même.
Qu'est-ce que cela me donne en tant que développeur?
Pour commencer, il vous aide à rester SEC. Soit votre schéma, soit vos classes de modèles font autorité et l'autre est généré automatiquement, ce qui réduit le nombre de bogues et la quantité de code de plaque de chaudière.
Il aide au 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/sérialiser vous-même. En outre, il vous permet de récupérer des objets entièrement formés à partir de la base de données plutôt que de simplement aligner des objets que vous devez envelopper vous-même.
En quoi mon code sera-t-il différent des instructions SELECT individuelles que j'utilise maintenant?
Étant donné que vos requêtes renverront des objets plutôt que des 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 pouvez généralement écrire du SQL directement lorsque vous en avez besoin, mais pour la plupart des opérations (CRUD), l'ORM simplifie le code d'interaction avec les objets persistants.
Comment cela aidera-t-il avec l'accès et la sécurité de la base de données?
De manière générale, les ORM ont leur propre API pour créer des requêtes (par exemple, l'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. Un tel SQL injecté vous est responsable de vous-même, mais si vous évitez d'utiliser de telles fonctionnalités, l'ORM devrait prendre soin de nettoyer automatiquement les données utilisateur.
Comment découvre-t-il le schéma de base de données et les informations d'identification de l'utilisateur?
De nombreux ORM sont fournis avec des outils qui inspecteront un schéma et créeront un ensemble de classes de modèle qui vous permettront d'interagir avec les objets de la base de données. Les informations d'identification de l'utilisateur de la base de données 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 blog sympa qui résume les fonctionnalités essentielles dont vous pourriez avoir besoin dans votre DAL/ORM et pourquoi écrire votre propre 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. La gestion du mappage d'objets 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:
- Abstraction de la base de données
- Mentalité de conception centrée sur l'API
- Niveau élevé == Moins de soucis au niveau fondamental (cela a été pensé pour vous)
Je dois dire que travailler avec un ORM est vraiment l'évolution des applications basées sur une base de données. Vous vous inquiétez moins du SQL standard que vous écrivez toujours, et plus de la façon dont les interfaces peuvent fonctionner ensemble pour créer un système très simple.
J'aime ne pas avoir à me soucier de INNER JOIN et SELECT COUNT (*). Je travaille juste dans mon abstraction de haut niveau, et j'ai pris soin de l'abstraction de la base de données en même temps.
Cela dit, je n'ai jamais vraiment rencontré un 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. Cependant, cela ne veut pas dire que ce cas n'existe pas, c'est un problème très réel pour certains développeurs.
Je ne peux pas parler pour les autres ORM, juste Hibernate (pour Java).
Hibernate me donne ce qui suit:
- Met à jour automatiquement le schéma des tables sur le système de production au moment de l'exécution. Parfois, vous devez toujours mettre à jour manuellement certaines choses.
- Crée automatiquement des clés étrangères qui vous empêchent d'écrire du mauvais code qui crée des données orphelines.
- Implémente le regroupement de connexions. Plusieurs fournisseurs de regroupement de connexions sont disponibles.
- Met en cache les données pour un accès plus rapide. Plusieurs fournisseurs de mise en cache sont disponibles. Cela vous permet également de regrouper de nombreux serveurs pour vous aider à évoluer.
- 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.
- Rendez les requêtes plus faciles à écrire. La requête suivante qui vous obligerait normalement à écrire trois fois "join" peut être écrite comme ceci:
- "de la facture i où i.customer.address.city =?" cela récupère toutes les factures avec une ville spécifique
- une liste d'objets Facture est retournée. Je peux ensuite 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 effectuer une rétro-ingénierie d'une base de données pour créer le schéma de mise en veille prolongée (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 pour toute nouvelle technologie, mais je pense que cela en vaut la peine.
Si nécessaire, vous pouvez toujours descendre 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. Un mappeur objet-relationnel prend les données, crée un shell autour 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 le considérer comme un tableau de lignes, vous avez maintenant une liste d'objets que vous pouvez manipuler comme vous le feriez pour n'importe quel autre et simplement appeler obj.Save () lorsque vous avez terminé.
Je vous suggère de jeter un oeil à certains des ORM qui sont en cours d'utilisation, un de mes favoris est l'ORM utilisé dans le cadre python, Django . L'idée est que vous écriviez 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 devant être exécutée avant l'insertion des données.
Personnellement, je n'ai pas eu une grande expérience de l'utilisation de la technologie ORM à ce jour. Je travaille actuellement pour une entreprise qui utilise nHibernate et je ne peux vraiment pas continuer. Donnez-moi un proc stocké et DAL tous les jours! Plus de code bien sûr ... mais aussi plus de contrôle et un code plus facile à déboguer - d'après mon expérience avec une première version de nHibernate, il faut l'ajouter.
Pour un podcast qui traite de l'ORM en détail, consultez le lien suivant. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed
Qu'est-ce que cela me donne en tant que développeur?
Vous fait gagner du temps, car vous n'avez pas à coder la partie d'accès à la base de données.
En quoi mon code sera-t-il différent 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 aidera-t-il avec l'accès et la sécurité de la base de données?
La plupart des frameworks essaient d'adhérer aux meilleures pratiques de la base de données, le cas échéant, telles que 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 bogues qui pourraient ouvrir des trous inattendus.
Comment découvre-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, les classes spécifiques à MySQL) fournissent l'implémentation qui interroge le schéma db, traite les mappages de classe 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 offrent 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 c'est bien d'avoir la garantie du cadre.
Les ORM fonctionnent de deux manières: 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 le schéma mappé, l'ORM peut être en mesure de créer (recréer) votre structure de base de données pour vous. Les autorisations de base de données doivent probablement encore être appliquées à la main ou via SQL personnalisé.
En règle générale, les informations d'identification fournies par programmation via l'API ou à l'aide d'un fichier de configuration - ou les deux, les valeurs par défaut provenant d'un fichier de configuration, mais pouvant être remplacées dans le code.
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 du SQL complexe et réglé manuellement
- 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é
... alors 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 d'écrire 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 créer 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 recommanderais 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 peuvent ressembler d'un point de vue descendant.
ma préoccupation avec les frameworks ORM est probablement la chose même qui le rend attrayant pour de nombreux développeurs.
sachez que cela évite de se soucier de ce qui se passe au niveau de la base de données. La plupart des problèmes que nous voyons au cours de l'exécution quotidienne 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 atteignent la base de données, ou s'ils le font, ils ne savent pas comment les changer ou les optimiser.
{Je me rends compte que cela peut être une réponse contradictoire :)}