Quels sont les avantages de l'utilisation d'un ORM ?

Question

En tant que développeur web cherchant à passer de sites PHP codés à la main à des sites basés sur des frameworks, j'ai vu beaucoup de discussions sur les avantages d'un ORM par rapport à un autre. Il semble être utile pour les projets d'une certains ( ?) et encore plus important pour les applications de niveau entreprise.

Qu'est-ce que cela m'apporte en tant que développeur ? En quoi mon code sera-t-il différent des instructions SELECT individuelles que j'utilise actuellement ? Comment va-t-il m'aider à accéder à la base de données et à en assurer la sécurité ? Comment se renseigne-t-il sur le schéma de la base de données et les informations d'identification des utilisateurs ?

Edit : @duffymo a souligné ce qui aurait dû être évident pour moi : ORM est seulement utile pour le code OOP. Mon code n'est pas OO, donc je n'ai pas rencontré les problèmes que ORM résout.

Answer 1

Je dirais que si vous ne traitez pas d'objets, il y a peu d'intérêt à utiliser un ORM.

Si vos tables/colonnes relationnelles correspondent 1:1 aux objets/attributs, l'utilisation d'un ORM n'a pas beaucoup d'intérêt.

Si vos objets n'ont pas de relations 1:1, 1:m ou m:n avec d'autres objets, l'utilisation d'un ORM n'a pas beaucoup d'intérêt.

Si vous disposez d'un langage SQL complexe, réglé à la main, l'utilisation d'un ORM n'a pas beaucoup d'intérêt.

Si vous avez décidé que l'interface de votre base de données sera constituée de procédures stockées, il n'y a pas vraiment d'intérêt à utiliser un ORM.

Si vous disposez d'un schéma patrimonial complexe qui ne peut pas être remanié, l'utilisation d'un ORM n'a pas beaucoup d'intérêt.

Voici donc l'inverse :

Si vous disposez d'un modèle d'objet solide, avec des relations entre les objets de type 1:1, 1:m et m:n, que vous n'avez pas de procédures stockées et que vous aimez le SQL dynamique que vous offre une solution ORM, vous pouvez utiliser un ORM.

Les décisions de ce genre sont toujours un choix. Choisir, mettre en œuvre, mesurer, évaluer.

Answer 2

Les ORM sont présentés comme 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 fonctionnent dans de petits projets. Voici les problèmes que nous avons rencontrés avec eux, en particulier avec nHibernate :

1. Configuration : Les technologies ORM nécessitent des fichiers de configuration pour mettre en correspondance les schémas de tables avec 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 impossible à maintenir 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 de frameworks. Les développeurs sont obligés de trouver des solutions de contournement 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 être amenés à utiliser régulièrement des procédures stockées pour tout ce qui est plus complexe qu'une simple sélection.

3. 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 normalisés dans l'industrie informatique. Ces bibliothèques et langages d'interrogation 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.

4. Langages d'interrogation d'objets : De nouveaux langages de requête appelés "Object Query Languages" sont fournis pour effectuer des requêtes sur le modèle objet. Ils génèrent automatiquement des requêtes SQL contre la base de données et l'utilisateur est abstrait du processus. Pour les développeurs orientés objet, cela peut sembler un avantage car ils ont l'impression que le problème de l'écriture du SQL est résolu. En pratique, le problème est que ces langages d'interrogation ne peuvent pas prendre en charge certaines des constructions SQL intermédiaires ou 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. Les performances : 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. Ces opérations sont coûteuses en termes de traitement et contribuent à la dégradation des performances des opérations de mappage. Les requêtes objet qui sont traduites pour produire des requêtes non optimisées sans possibilité de les ajuster entraînent des pertes de performance significatives et une surcharge des systèmes de gestion des bases de données. L'optimisation des performances du SQL est presque impossible, car les frameworks offrent peu de flexibilité pour contrôler le SQL généré automatiquement.

6. Accouplement serré : Cette approche crée une dépendance étroite entre les objets du modèle et les schémas de la base de données. Les développeurs ne veulent pas d'une corrélation biunivoque entre les champs de la base de données et les champs de la classe. La modification du schéma de la base de données a des répercussions sur le modèle d'objet et la configuration du mappage, et vice versa.

7. Caches : Cette approche nécessite également l'utilisation de caches et de contextes d'objets qui sont 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 en cache. Ces caches, s'ils ne sont pas maintenus et synchronisés dans une implémentation à plusieurs niveaux, peuvent avoir des ramifications significatives en termes d'exactitude des données et de concurrence. Il est souvent nécessaire de brancher des caches tiers ou des caches externes 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

Answer 3

À un niveau très élevé : Les ORM aident à réduire l'inadéquation de l'impédance Objet-Relationnel. Ils vous permettent de stocker et d'extraire des objets complets et vivants d'une base de données relationnelle sans avoir à faire vous-même beaucoup d'analyse/de sérialisation.

Qu'est-ce que cela m'apporte en tant que développeur ?

Pour commencer, il vous aide à rester SÈCHE. Soit votre schéma, soit vos classes de modèle font autorité et l'autre est généré automatiquement, ce qui réduit le nombre de bogues et la quantité de code passe-partout.

Il aide au marshaling. Les ORM gèrent généralement la mise en forme des valeurs des colonnes individuelles dans les types appropriés afin que vous n'ayez pas à les analyser/sérialiser vous-même. De plus, cela vous permet de récupérer des objets complets à partir de la base de données plutôt que de simples objets en ligne que vous devez envelopper vous-même.

En quoi mon code sera-t-il différent des instructions SELECT individuelles que j'utilise actuellement ?

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

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

En général, les ORM ont leur propre API pour construire 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. Vous êtes responsable de l'assainissement de ce SQL injecté, mais si vous évitez d'utiliser de telles fonctionnalités, l'ORM devrait s'occuper automatiquement de l'assainissement des données utilisateur.

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

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

Answer 4

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 caractéristiques essentielles dont vous pouvez avoir besoin dans votre DAL/ORM et pourquoi écrire le vôtre devient une mauvaise idée avec 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 mapping objet n'est qu'une facette des ORMs. Le site Dossier actif est un bon exemple de l'utilité des ORM dans les scénarios où les objets correspondent 1:1 aux tables.

Answer 5

Je ne peux pas parler des autres ORM, mais seulement d'Hibernate (pour Java).

Hibernate me donne le résultat suivant :

• Met automatiquement à jour le schéma des tables du système de production au moment de l'exécution. Parfois, vous devez encore mettre à jour certaines choses manuellement.
• Crée automatiquement des clés étrangères, ce qui vous évite d'écrire un mauvais code qui crée des données orphelines.
• Implémente la mise en commun des connexions. Plusieurs fournisseurs de mise en commun des connexions sont disponibles.
• Met les données en cache 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 aux bases de données plus transparent afin que vous puissiez facilement porter votre application vers une autre base de données.
• Faciliter l'écriture des requêtes. La requête suivante, qui nécessiterait normalement d'écrire trois fois "join", peut être écrite comme suit :
  • "from Invoice i where i.customer.address.city = ?" ceci récupère toutes les factures avec une ville spécifique.
  • une liste d'objets Facture est renvoyée. Je peux alors appeler invoice.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 hibernate (je n'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.