Êtes-vous pour ou contre les ORM ?
Un blogueur invite à tenir le bâton par le milieu

Le , par tarikbenmerar, Chroniqueur Actualités
S'il y a bien une constante dans la nature humaine, c'est celle qui rend tellement rare qu'un choix ou un avis particulier fasse partout l'unanimité.
Le monde de l'informatique et du développement ne dérogent pas à cette règle. C'est même un domaine où les guéguerres idéologiques peuvent être les plus enflammées et les opinions des plus tranchées.

Des décennies durant, de vifs débats reviennent encore et encore dans les communautés de développement : Big Endian vs Little Endian, EMACS vs Vi(m) ou Java vs .NET, pour ne citer que les plus notables.

Mais au-delà du débat, constructif ou répétitif, il est incontestable que le vrai gagnant est celui qui arrive à synthétiser les qualités et les faiblesses de chaque opinion dans un contexte précis. Qui arrive à en extraire l'essence pour adapter son choix au besoin particulier de chacun.

C'est avec cette philosophie qu'aborde Andy Boothe le débat sur les ORM dans un billet de son blog SIGPWNED.

L'ORM (mapping objet-relationnel) est une technique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé.



Andy Boothe commence par étayer les avis de chacun, pour nous laisser les meilleures pratiques pour la fin. Entre les modeleurs (les pro-ORM) et les persistants (les anti-ORM), Andy préconise les habitudes suivantes :

  • Utilisez des objets modèles les plus simples possible, lors de l'utilisation de l'ORM. Il faut être vigilant de ne pas sur-simplifier et s'assurer que les modèles reflètent tout simplement l'ancien modèle de données. Autrement on fera face à un effort non négligeable avec l'ORM pour s'assurer que la persistance marche comme prévu pour ne pas chercher des méthodes et des propriétés manquantes.
  • Si vous n'utilisez pas l'ORM, vous devez probablement définir des DAO (Data Access Objects) ou des méthodes de requête et de persistance, pour éviter un couplage fort entre la couche modèle et la couche persistance. Sinon, vous vous retrouverez avec du SQL dans les objets modèles et avec une dépendance forcée.
  • Si vous savez que les schémas d'accès aux données seront simples, mais vous ne les cernez pas entièrement, vous devriez songer à utiliser un ORM. Même si les ORM peuvent rendre difficile de créer et de déboguer les requêtes complexes, ils s'avèrent efficaces et permettent de gagner beaucoup de temps pour des requêtes simples.
  • Si vous savez que les schémas d'accès aux données seront complexes ou que divers mécanismes spécifiques à un SGBD particulier seront utilisés, il est préférable d'éviter les ORM. Même si certains ORM, tels que Hibernate, permettent un accès facile à la connexion sous-jacente, les avantages seront perdus si vous vous retrouvez à utiliser beaucoup de SQL personnalisé.
  • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.


Et vous ?

Êtes-vous pour ou contre les ORM ?
Pouvez-vous justifier votre choix ?
Votre choix s'adapte-t-il au type de développement que vous faites ?

Source : Billet de blog de sigpwned


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Conaclos Conaclos - Nouveau membre du Club https://www.developpez.com
le 15/08/2012 à 12:15
Je suis personnellement pour les ORM mais différent de ceux existant actuellement.

Un ORM apporte une souplesse, une simplicité déconcertante. Il permet un développement plus fiable et plus robuste.

La performance pourrait être au rendez-vous en utilisant un compilateur qui s'adapte à un SGBD particulier et élimine les couches d'abstraction pour faire des appels directes à des requêtes préparés.

Pour le développement Object, l'ORM c'est un véritable atout. Reste à gommer ses faiblesse notamment par l'intermédiaire d'un compilateur.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 15/08/2012 à 13:05
Je ne suis pas forcément pour ou contre.
L'article cite assez bien les avantages et inconvénients de l'utilisation d'un ORM.

Contre :
  • Pour ma part ayant déjà utilisé Doctrine, je trouve qu'on est techniquement limité pour faire des requêtes complexes, il faut alors passer par le DQL (requête doctrine, équivalent de HQL pour Hibernate), et là encore je ne suis pas sur d'arriver à ce que je veux.
  • Bien sur il y a cette grosse couche d'abstraction qui peut nuire aux performances... et d'après ce que j'ai compris un ORM peut effectuer plus de requête que nécessaire parfois.
  • Bien maitriser un ORM demande beaucoup de temps de formation (les entités, les annotations, les contraintes...).


Pour :
  • Dans l'ensemble, utiliser des objets et leurs méthodes facilite le développement, on évite de passer par des méthodes contenant de longues chaines de requêtes SQL.
  • Les données sont persistants.
  • Notre application devient multi-BDD (ex: fonctionne aussi bien sous MySQL que sous PostgreSQL ou autre...)
Avatar de Stopher Stopher - Membre averti https://www.developpez.com
le 15/08/2012 à 13:28
Pour et contre,

pour moi il est essentiel de maitriser ce qui se passe lorsque l'on code.

Il convient d'apprendre à utiliser les bases de données sans ORM, et lorsque l'on a le temps/l'occasion/la contrainte/la volonté d'utiliser/d'apprendre à utiliser un ORM.

L'utilisation d'un ORM apporte aussi de nouvelles contraintes technique qui ajoute encore un "pseudo langage" à apprendre qui va différer d'une techno à une autre ...

N'étant personnellement pas lié à un langage particulier je me méfie comme la peste des couches d'abstraction qui permettent "d'arriver plus vite" à ses fins. de plus si le code se veut maintenable, la lib ORM doit être maitrisée par ses mainteneurs .. bref ...

ça peut vous simplifier la vie, comme la rendre plus compliquée ... à utiliser en connaissance de cause

Ch.
Avatar de kain_tn kain_tn - Membre chevronné https://www.developpez.com
le 15/08/2012 à 14:13
Citation Envoyé par tarikbenmerar  Voir le message
Êtes-vous pour ou contre les ORM ?
Pouvez-vous justifier votre choix ?

Tout dépend du type de développement que l'on fait je pense:
  • si le logiciel produit doit pouvoir supporter différentes bases de données (par exemple une solution de BI ou un CMS), alors le choix d'un ORM peut être justifié
  • dans tous les autres cas, passer par un ORM coûte cher en temps de formation, apporte moins de souplesse et produit de moins bonnes performances que si le développeur avait passé le même temps à apprendre à utiliser correctement une BDD


Citation Envoyé par tarikbenmerar  Voir le message
Votre choix s'adapte-t-il au type de développement que vous faites ?

Développant sur des SI sur mesure, je n'ai effectivement pas l'intérêt d'un ORM. Je préfère former mes développeurs correctement, et faire un bon découplage des couches (utilisation de DAO si le langage le permet, création d'une abstraction entre la BDD et le code avec l'utilisation de vues et de procédures stockées)
Avatar de erwanlb erwanlb - Inactif https://www.developpez.com
le 15/08/2012 à 14:57
Pouvez-vous justifier votre choix ?

Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...

Pas besoin non plus de savoir systématiquement ce qui se passe derrière comme on a pas besoin d'être mécano pour rouler vite en voiture...

Pour la formation, elle peut être nécessaire aussi quand on utilise pas d'ORM...
Avatar de rawsrc rawsrc - Modérateur https://www.developpez.com
le 15/08/2012 à 15:37
Bonjour,
Citation Envoyé par erwanlb  Voir le message
Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...

Faut pas pousser non plus : comme si gérer une connexion à une BDD filait obligatoirement des maux de têtes et concernant le langage SQL, il faut le mettre en parallèle avec l'apprentissage de ceux embarqués par les ORM le HQL et DQL (pour les plus connus). Pour moi c'est kif-kif.

Le seul hic avec l'abus des ORM c'est quand tu tombes sur un environnement qui t'oblige pour des raisons de sécurité, de performance... à ne passer que par des procédures stockées et là comme je l'ai vu récemment l'abus d'ORM nuit gravement à la productivité.

Alors sans être expert en SQL, il faut quand même avoir de bonnes notions en bases de données et en langage SQL, le reste c'est un plus mais à consommer avec modération.
Avatar de kain_tn kain_tn - Membre chevronné https://www.developpez.com
le 15/08/2012 à 15:46
Citation Envoyé par erwanlb  Voir le message
Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...

Euh, le .Net est orienté objet il me semble, donc les connexions etc ça se gère une fois, pas plus. Après pour ce qui est de l'intérêt, c'est encore une fois une question de performances (et donc aussi de coûts).

Citation Envoyé par erwanlb  Voir le message
Pas besoin non plus de savoir systématiquement ce qui se passe derrière comme on a pas besoin d'être mécano pour rouler vite en voiture...

Si je comprends où tu veux en venir, je trouve que ta comparaison est assez mal choisie: là, celui qui roule vite ou pas serait l'utilisateur final, tandis que le développeur serait plutôt du côté de celui qui construit la voiture donc bon... Une meilleure comparaison serait peut être la boite de vitesses automatique contre la boite manuelle... Pour une conduite de tous les jours, tu peux utiliser l'une ou l'autre. En revanche sur un circuit, la boite auto c'est pas forcément ce qui se fait de mieux...

Citation Envoyé par erwanlb  Voir le message
Pour la formation, elle peut être nécessaire aussi quand on utilise pas d'ORM...

Tout à fait d'accord! Elle est nécessaire! En revanche, le résultat n'est pas du tout le même.
Avatar de pcaboche pcaboche - Rédacteur https://www.developpez.com
le 15/08/2012 à 18:17
Citation Envoyé par tarikbenmerar  Voir le message
  • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.

Rare ? Au contraire, c'est super répandu !

J'irais même plus loin: c'est quoi l'intérêt de développer un Système d'Information incapable de tenir la charge ?

Là où je suis d'accord, c'est qu'un ORM dans ce cas, c'est pas la joie. Typiquement:
- ça créé une transaction (par ce qu'on en a besoin pour assurer l'intégrité des données)
- ça fait plein de petites requêtes qui, cumulées, utilisent pas mal de ressources
- pendant tout le temps où la transaction est restée ouverte, d'autres applications ont eu le temps de faire des timeouts...

À ce niveau là, je préfère une bonne procédure stockée qui fait des bons gros traitements par lots, et de manière efficace.

C'est vrai que la POO c'est rassurant parce qu'on comprend les interactions entre objets, et que l'algèbre relationnelle ça fait peur à pas mal de gens. C'est vrai que certaines procédures stockées font mal à la tête quand on doit les relire (surtout si elles sont mal indentées, c'est une horreur !) mais souvent, quand on voit tout ce qu'il faut écrire en POO pour arriver au même résultat (mais en moins performant), c'est même pas la peine !

Un autre avantage des procédures stockées, c'est que si on se rend compte d'un problème, on a juste à modifier la procédure pour que les changements prennent immédiatement effet, pas besoin de tout recompiler et redéployer...

J'ai un collègue développeur qui m'a raconté qu'il ne s'était jamais intéressé au SQL... jusqu'à ce qu'il me rencontre et qu'il voie ce qu'il est possible de faire avec du SQL. Depuis il me pose plein de questions.

À la base, je ne suis pas partisan d'une solution plutôt qu'une autre. Mais quand on a des deadlines parfois assez serrées, on va vers la solution qui permet de réduire les temps de développement. Et quand à cela s'ajoutent des contraintes de performance...
Avatar de imikado imikado - Rédacteur https://www.developpez.com
le 15/08/2012 à 18:36
Bonjour,
Je préconise l'utilisation d'ORM:
  • ça permet de centraliser les requêtes, rangées par table, plus pratique à maintenir. (MVC oblige)
  • on identifie les paramètres des requêtes (pratique pour ajouter les bons index, plus facile de sécuriser)


Je conseille l'utilisation de requêtes SQL dans les classes modèles à la place de la syntaxe objet ORM
  • Plus simple à écrire/décoder (pour la maintenance/reprise de code), pas besoin d'apprendre un nouveau language
  • Plus facile pour travailler avec le dba*, lorsqu'il faut optimiser les requêtes...
  • Plus performant


En faisant ainsi on bénéficie des avantages de la séparation de la couche modèle avec la l'organisation des requêtes par table, sans trop perdre en performances.

*database administrator

note:On fait ainsi avec zend framework 1.*, et c'est le choix que j'ai également fait pour mon framework php
Avatar de erwanlb erwanlb - Inactif https://www.developpez.com
le 15/08/2012 à 18:39
Citation Envoyé par rawsrc  Voir le message
Bonjour,

Faut pas pousser non plus : comme si gérer une connexion à une BDD filait obligatoirement des maux de têtes et concernant le langage SQL, il faut le mettre en parallèle avec l'apprentissage de ceux embarqués par les ORM le HQL et DQL (pour les plus connus). Pour moi c'est kif-kif..

Pourquoi se donner du boulot en plus ? Je fais pas du bénévolat à mon boulot
Offres d'emploi IT
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil