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

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



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

http://idelways.developpez.com/news/images/orm.jpg

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 ?

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

Source : Billet de blog de sigpwned

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.

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

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.

Citation:

---

Envoyé par tarikbenmerar

:fleche: Êtes-vous pour ou contre les ORM ?
:fleche: 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

:fleche: 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)

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

Bonjour,

Citation:

---

Envoyé par erwanlb

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.

Citation:

---

Envoyé par erwanlb

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

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

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.

Citation:

---

Envoyé par tarikbenmerar

• 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 ? 8O 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 ? :koi:

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... :mrgreen:

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 :)

Citation:

---

Envoyé par rawsrc

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 :)

Citation:

---

Envoyé par kain_tn

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



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



Tout à fait d'accord! Elle est nécessaire! En revanche, le résultat n'est pas du tout le même.

---

Je connais le langage SQL mais entre l'utiliser dans mon code C# et utiliser un ORM...y a pas photo....

OK pour la boite manuelle....mais un mauvais pilote ne saurait pas passer les vitesses rapidement...et je dirais qu'un ORM c'est plutôt une boite manuelle avec des palettes plutôt qu'un levier...en tout cas dans ma manière de coder... :mrgreen:

Citation:

---

Envoyé par pcaboche

Rare ? 8O 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 ? :koi:

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... :mrgreen:

---

Tu peux utiliser un ORM et des procédures stockées...

Vu les arguments utilisés on en est au stade d'un débat genre Win/Linux, iOS/Android....

Est ce que ceux qui sont contre les ORM les connaisse et les ont utilisé ?

Citation:

---

Envoyé par imikado

[*]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[/LIST]

---

En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....

Citation:

---

Envoyé par erwanlb

En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....

---

Un des problèmes que j'ai déjà rencontré avec l'utilisation de certains ORM était l'utilisation systématique de "select *", donc oui, au niveau perf on peut faire mieux :)
Perso j'ai pu faire des benchmarks d'ORM et j'arrivai à des ratio assez important en fonction du nombre d'éléments retournés*

Pour l'optimisation, je parle de transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...
Ca permet une meilleur communication entre les différentes postes qui interviennent sur le projet (on va pas demander au dba d'apprendre le langage doctrine, ou autre...)


* j'avais fait une simple page bouclant sur 100 000 articles, et écrivant le titre, l'auteur et la catégorie dans un fichier texte, et on pouvait voir une différence très importante entre les ORM :(

Citation:

---

Envoyé par erwanlb

En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....

---

me rappel encore d'un reportage d'étudiant qui disait que ça servait à rien le sql parce que les orm faisait tout le boulot....... et par la suite tu avais des ssii qui ralait car trop de gens ne maitrisait pas le sql.....

Citation:

---

Envoyé par imikado

Un des problèmes que j'ai déjà rencontré avec l'utilisation de certains ORM était l'utilisation systématique de "select *", donc oui, au niveau perf on peut faire mieux :)
Perso j'ai pu faire des benchmarks d'ORM et j'arrivai à des ratio assez important en fonction du nombre d'éléments retournés*

Pour l'optimisation, je parle de transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...
Ca permet une meilleur communication entre les différentes postes qui interviennent sur le projet (on va pas demander au dba d'apprendre le langage doctrine, ou autre...)


* j'avais fait une simple page bouclant sur 100 000 articles, et écrivant le titre, l'auteur et la catégorie dans un fichier texte, et on pouvait voir une différence très importante entre les ORM :(

---

J'ai déjà vu ce genre de benchmark....qui sont généralement contesté dans les méthodes utilisées...même si on sait que l'ORM sera un peu moins rapide...

Ca dépend grandement de la destination de l'application et de la manière dont elle a été conçue

Citation:

---

Envoyé par marc.collin

me rappel encore d'un reportage d'étudiant qui disait que ça servait à rien le sql parce que les orm faisait tout le boulot....... et par la suite tu avais des ssii qui ralait car trop de gens ne maitrisait pas le sql.....

---

Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...

Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL

Citation:

---

Envoyé par erwanlb

Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...

Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL

---

c'est justement mon point de vue et je suis bien content d'avoir une plusieurs cours sur le sujet.

"Êtes-vous pour ou contre les ORM ?" Pourquoi pour ou contre ?
Le choix de la méthode de persistance s'impose souvent par le contexte, ou par des décisions de l'entreprise prise dans le passé.
Pour un même projet, il peut y avoir plusieurs applications qui n'utilisent pas toutes les mêmes méthodes de persistance. Le temps fait son œuvre.
Je n'ai pas encore rencontré ce choix binaire...

Globalement, c'est toujours une question de besoin. Si on veut obtenir de bonnes performances, un framework de persistance comme MyBatis me parait bien plus approprié pour simplement prendre en charge la plomberie. Un ORM peut être intéressant si on veut se laisser la possibilité de changer de SGBD, mais c'est loin d'être le cas général. Autrement, un ORM apporte autant de complexité qu'il en supprime, donc à quoi bon ?

Citation:

---

Envoyé par erwanlb

J'ai déjà vu ce genre de benchmark....qui sont généralement contesté dans les méthodes utilisées...même si on sait que l'ORM sera un peu moins rapide...

Ca dépend grandement de la destination de l'application et de la manière dont elle a été conçue

---

Pour jouer la carte de la transparence tu trouveras avec ce post le périmètre du benchmark qui est tres simple:

Une base de donnée avec 100 000 entrées dans une table article
l'outil time (linux) utilisé 10 fois sur une page listant dans un tableau html ces 100 000 articles

Les résultats:

• sans framework ni orm: entre 0m0.032s et 0m0.041s
• ORM de Zend framework: entre 0m16.817s et 0m19.180s
• ORM du mkframework: entre 0m3.495s et 0m3.648s

Je joint les fichiers de logs de la commande time,

Ci dessous le code du fichier sans appel orm/mkframework (du php pure)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

<?php $oPdo = new PDO('mysql:host=localhost;dbname=benchmark', 'root', 'pass'); $stm = $oPdo->prepare('select * from article'); $result = $stm->execute(); ?> <table> <tr> <th>id</th> <th>titre</th> <th>resume</th> <th>auteur</th> </tr> <?php while( $oArticle = $stm->fetchObject()) : ?> <tr> <td><?php echo $oArticle->id ?></td> <td><?php echo $oArticle->titre ?></td> <td><?php echo $oArticle->resume ?></td> <td><?php echo $oArticle->auteur ?></td> </tr> <?php endwhile ?> </table>

---

je peux si besoin uploader le dump des 100 000 articles dans une table article, contenant un id, un titre, un resume et un auteur

Code:

---

1 2 3 4 5 6 7

CREATE TABLE `article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `titre` varchar(50) NOT NULL, `resume` text NOT NULL, `auteur` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---

note: pour le tester chez soi, il faut telecharger le zendframework et changer l'include path dans projet "zf",
http://framework.zend.com/releases/Z...12-minimal.zip


et concernant le projet mkframework, il faut également télécharger le framework et modifier l'adresse dans le fichier conf/site.ini.php
http://mkdevs.com/telecharger.html

Citation:

---

Envoyé par imikado

... transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...

---

:zekill: Le DBA n'a pas vocation à trier les ordures !

Citation:

---

Envoyé par Pomalaix

:zekill: Le DBA n'a pas vocation à trier les ordures !

---

Il nous arrive assez souvent de discuter avec le DBA de certaines requêtes plus ou moins complexe, et le fait de les centraliser permet de les trouver plus facilement.

Ce n'est pas lui demander de trier les ordures (on va pas lui transmettre toutes les requêtes), c'est permettre une meilleure coopération entre les services ;)

Que ce soit le dba, ou même un nouveau développeur qui reprend le projet pour l'optimiser, il est toujours pratique de pouvoir facilement trouver l'ensemble des requêtes :)

Citation:

---

Envoyé par imikado

Pour jouer la carte de la transparence tu trouveras avec ce post le périmètre du benchmark qui est tres simple:

Une base de donnée avec 100 000 entrées dans une table article
l'outil time (linux) utilisé 10 fois sur une page listant dans un tableau html ces 100 000 articles

Les résultats:

• sans framework ni orm: entre 0m0.032s et 0m0.041s
• ORM de Zend framework: entre 0m16.817s et 0m19.180s
• ORM du mkframework: entre 0m3.495s et 0m3.648s

Je joint les fichiers de logs de la commande time,

Ci dessous le code du fichier sans appel orm/mkframework (du php pure)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

<?php $oPdo = new PDO('mysql:host=localhost;dbname=benchmark', 'root', 'pass'); $stm = $oPdo->prepare('select * from article'); $result = $stm->execute(); ?> <table> <tr> <th>id</th> <th>titre</th> <th>resume</th> <th>auteur</th> </tr> <?php while( $oArticle = $stm->fetchObject()) : ?> <tr> <td><?php echo $oArticle->id ?></td> <td><?php echo $oArticle->titre ?></td> <td><?php echo $oArticle->resume ?></td> <td><?php echo $oArticle->auteur ?></td> </tr> <?php endwhile ?> </table>

---

je peux si besoin uploader le dump des 100 000 articles dans une table article, contenant un id, un titre, un resume et un auteur

Code:

---

1 2 3 4 5 6 7

CREATE TABLE `article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `titre` varchar(50) NOT NULL, `resume` text NOT NULL, `auteur` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---

note: pour le tester chez soi, il faut telecharger le zendframework et changer l'include path dans projet "zf",
http://framework.zend.com/releases/Z...12-minimal.zip


et concernant le projet mkframework, il faut également télécharger le framework et modifier l'adresse dans le fichier conf/site.ini.php
http://mkdevs.com/telecharger.html

---

J'fais pas de dév web donc les ORM web et leurs bienfaits ou méfaits sont une totale inconnue pour moi :)

Citation:

---

Envoyé par Traroth2

Globalement, c'est toujours une question de besoin. Si on veut obtenir de bonnes performances, un framework de persistance comme MyBatis me parait bien plus approprié pour simplement prendre en charge la plomberie. Un ORM peut être intéressant si on veut se laisser la possibilité de changer de SGBD, mais c'est loin d'être le cas général. Autrement, un ORM apporte autant de complexité qu'il en supprime, donc à quoi bon ?

---

Quel complexité ???

Citation:

---

Envoyé par erwanlb

J'fais pas de dév web donc les ORM web et leurs bienfaits ou méfaits sont une totale inconnue pour moi :)

---

C'était pour répondre sur la crédibilité des benchmarks, ici j'indique que les ORM ne se valent pas au niveau perf, et je fourni ma base de benchmark pour appuyer mon argumentation ;)

Citation:

---

Envoyé par imikado

C'était pour répondre sur la crédibilité des benchmarks, ici j'indique que les ORM ne se valent pas au niveau perf, et je fourni ma base de benchmark pour appuyer mon argumentation ;)

---

Il y en a qui l'ont déjà fait mais des personnes plutôt experte mettaient à mal les procédures de test....pas pour dire que les ORM étaient mieux mais plutot sur les rapport entre avec ORM et sans...pour eux la différence n'était pas si grande que ça

Enfin moi j'suis pas expert, j'utilise toujours un EDM tout en connaissant SQL et ça me va très bien :mouarf:

Citation:

---

Envoyé par erwanlb

Quel complexité ???

---

Les ORM remplacent une tâche fastidieuse mais maitrisée, par une abstraction permettant un développement plus rapide sur des schémas simple, mais qui, comme toute abstraction, ajoute un lot de notion à appréhender pour avancer (Lazy/Deferred/Eager loading, etc) et peut également se révéler contre-productif, voire casse-gueule sur des schémas complexe.

Je plussoie Traroth2 de bon coeur cette fois. Le multi-sgbd est rarement quelque chose qu'on nous demande et ça veut aussi dire se passer de tout ce qui est trop spécifique au niveau BDD.
J'irai même plus loin, je ne pense pas que l'utilisation d'un ORM garantisse qu'on puisse changer de SGBD les yeux fermés à moins d'avoir une très bonne grosse suite de test sur chacune des DB visées.

Pour ma part, j'ai abandonné hibernate à cause des sentiments de perte de maîtrise qu'il nous procurait. Nous avons utilisé mybatis, puis nous passons petit à petit à JOOQ (Un DSL SQL pour java) car il nous apporte les mêmes avantages que mybatis mais avec une meilleure protection contre la régression.

Je suis pas contre un ORM dans le cas où l'on est souvent amené à manipuler des graphes complexes, cependant l'utiliser efficacement est difficile, parfois plus que le problème qu'on essaie de résoudre avec. Donc pour ma part, j'opte pour un simple mapper qui m'épargne le plus pénible de JDBC, je code plus de choses à la main mais les performances sont excellentes, optimiser mes chargements est facile et ma maîtrise des interactions avec la BDD est totale. Pas de bidouillage de bytecode, pas de magie noire, pas de proxys qui explosent à la figure quand on les sérialise. Ca me va très bien.

Je reconnais les services rendus par ces outils mais parfois, aller au plus simple et sortir avec un truc facile à comprendre et à débugger quitte à coder plus, c'est une bonne solution. De toutes façons celui qui utilise un ORM juste pour ne pas avoir besoin de bien connaître le SQL, il est sûr de se vautrer.

Première fois que j'entends parler d'ORM :aie: :oops:

Cela dit, DAL, BLL, unit tests je connais.

Rem: .net developer

Citation:

---

Envoyé par Xinu2010

Les ORM remplacent une tâche fastidieuse mais maitrisée, par une abstraction permettant un développement plus rapide sur des schémas simple, mais qui, comme toute abstraction, ajoute un lot de notion à appréhender pour avancer (Lazy/Deferred/Eager loading, etc) et peut également se révéler contre-productif, voire casse-gueule sur des schémas complexe.

---

Ca dépend quel ORM tu utilises....

Un EDM sur .Net pour faire un truc pas compliqué c'est les doigts dans l'nez...

Simple question? Les BDD object , ça en est ou? ça permettrait justement de se passer des ORM sans sacrifier les performances non?

Citation:

---

Envoyé par erwanlb

Ca dépend quel ORM tu utilises....

Un EDM sur .Net pour faire un truc pas compliqué c'est les doigts dans l'nez...

---

Je précise que je ne connais pas les ORM de .NET, je n'ai d'expérience qu'avec doctrine (php) et hibernate (java).

C'est bien ce que je dis, pour faire un truc simple d'accord, mais dés que ça touche à des trucs plus compliqué et/ou à une forte volumétrie, faut avoir une très bonne connaissance de l'outil pour arriver à quelque chose.

Citation:

---

Envoyé par Xinu2010

Je précise que je ne connais pas les ORM de .NET, je n'ai d'expérience qu'avec doctrine (php) et hibernate (java).

C'est bien ce que je dis, pour faire un truc simple d'accord, mais dés que ça touche à des trucs plus compliqué et/ou à une forte volumétrie, faut avoir une très bonne connaissance de l'outil pour arriver à quelque chose.

---

Je dis pas compliqué parce que j'ai pas eut l'occasion d'être sur des projets où la vitesse est requise...

Juste que la avec ou sans ORM c'est pareil sauf pendant le développement où t'as pas besoin de t'arracher les cheveux avec des requêtes SQL...

En tout cas si les ORM existent et sont utilisés (c'est quand même pas des outils à l'abandon) c'est qu'ils sont utiles...

Citation:

---

Envoyé par scandinave

Simple question? Les BDD object , ça en est ou? ça permettrait justement de se passer des ORM sans sacrifier les performances non?

---

En php, on a PDO c'est déjà pas mal ;)

Personellement, les 2 seuls cas pour lesquels je n'utilise pas un ORM

- Si l'aspect performance ne me laisse pas le choix
- Si jai seulement quelque requete simpliste a faire alors je considere que faire la configuration et un 'mapping' serais probablement une perte de temps. Ajouter une librairie et toute ses dependances seulement pour 1-2 requetes... un peu tordu.

sinon moi et hibernate on est de bon amis :ccool:

Citation:

---

Envoyé par erwanlb

Je dis pas compliqué parce que j'ai pas eut l'occasion d'être sur des projets où la vitesse est requise...

---

Justement, si tu n'as jamais eu l'occasion de travailler sur des projets un tant soit peu sérieux (ex: des applications connectées aux marchés boursiers avec des transactions dans tous les sens) pourquoi tu te permets de donner ton avis ?

Et comme si cela ne suffisait pas, tu as l'outrecuidance de traiter certains de troll à mots à peine couverts et de sous-entendre qu'ils n'y connaissent rien... (là, c'est carrément se moquer du monde !)

Citation:

---

Envoyé par erwanlb

Juste que la avec ou sans ORM c'est pareil sauf pendant le développement où t'as pas besoin de t'arracher les cheveux avec des requêtes SQL...

---

Pas besoin d'être un expert en SQL pour faire des choses assez puissantes avec (il est bien sûr nécessaire de connaître les bases, mais il faut pas déconner non plus : c'est pas inhumain de connaître la différence entre un INNER, un OUTER et FULL join...).

C'est seulement quand les projets deviennent un peu sérieux (le genre de projet sur lesquels tu n'as, de ton propre aveu, jamais eu l'occasion de travailler) qu'on a besoin de regarder plus profondément dans les détails techniques du SGBD.

Si on a la chance d'avoir un collègue DBA (dans les petites entreprises, ce n'est pas toujours le cas et les développeurs jouent de rôle de factotum pour tout ce qui est ressources IT) c'est à ce moment qu'il faut se tourner vers lui pour discuter de son problème (et dans le pire des cas, la développeur et le DBA tombent d'accord : c'est l'architecte qui a pondu une abomination et maintenant il faut faire avec et bidouiller pour que ça ne plante pas trop).

Mais bon, quand on atteint ce niveau, c'est clair que ça ferait déjà longtemps que les ORM auraient été complètement à la ramasse...

Citation:

---

Envoyé par erwanlb

En tout cas si les ORM existent et sont utilisés (c'est quand même pas des outils à l'abandon) c'est qu'ils sont utiles...

---

Oui, les ORM ont leur utilité, au même titre que tous ces IDE qui permettent de faire du RAD (Rapid Application Development).

Ce qui m'a toujours amusé dans l'acronyme "RAD", c'est que cela ne veut pas dire "Développement d'Applications Rapides (comme on pourrait le penser de prime abord), mais "Développement Rapide d'Applications". Et dans les faits, c'est surtout: "Développement Rapide d'Applications (souvent très lentes et pas forcément faciles à maintenir)".

Et dans certains cas, ça se traduit par l'émergence d'un nouveau cycle de développement, que j'appelle "le cycle en 2 temps", malheureusement de plus en plus en vogue:

1er temps:
- l'entreprise exprime un besoin, elle fait un appel d'offres
- un consultant arrive et propose sa solution
- le consultant fait du RAD et respecte les délais
- le client est content, le consultant touche son gros chèque
- on met la solution en prod

2ème temps:
- au bout d'un certain temps d'exploitation, les problèmes de volumétrie/charge apparaissent
- on fait appel à un "spécialiste" pour corriger les défauts de "cette grosse m**** d'application" (dixit les utilisateurs)
- au bout d'un moment (3 ou 4 entreprises où on retrouve le même genre de problème), le "spécialiste" en a ras le c*l de devoir essuyer les m***** de ces consultants à la c*n

J'ai volontairement mis le terme "spécialiste" entre guillemets. En fait, ce qui en fait "spécialiste", c'est qu'il sait se retrousser les manches plutôt que d'utiliser des outils pour gamins censés lui mâcher le travail...

Il existe une variante, qui est le cycle en 3 temps. C'est la même chose que le cycle en 2 temps, mais avec une extension:

3ème temps:
- on sous-traite les évolutions du système dans un pays du tiers-monde où les gens s'en fichent parce qu'ils sont payés au lance-pierre pour travailler sur des applications où tout le monde a jeté l'éponge depuis longtemps
- on demande au dernier spécialiste en place de faire un "transfert de connaissances"
- si ce n'est pas déjà fait dans le 2ème temps (des raisons personnelles qui l'ont contraint à rester), le spécialiste se casse en disant à tout le monde d' "aller se faire ***** avec un ***** pendant qu'un ****** vous ***** le *****... " (utilisez votre générateur d'insultes préféré pour remplir les blancs)

Donc oui, les ORM et autres outils de RAD ont leur utilité : lancer la première phase du cycle en 2 ou 3 temps (c'est-à-dire pondre rapidement des applis, toucher son gros chèque et aller f**tre sa m***** ailleurs avant que les choses ne devennent un minimum sérieuses et que l'appli ne vous explose à la g*****).

Cordialement,

P.

@pcaboche
joli post, ça sent sacrément le vécu tout ça, dis donc...

Je ne vais pas me la jouer Mireille Dumas, mais tu devrais consulter pour te faire du bien. Tu ferais moins de cauchemars :mrgreen: idée de groupe : les informaticiens anonymes
:mouarf3:

Citation:

---

Donc oui, les ORM et autres outils de RAD ont leur utilité : lancer la première phase du cycle en 2 ou 3 temps (c'est-à-dire pondre rapidement des applis, toucher son gros chèque et aller f**tre sa m***** ailleurs avant que les choses ne devennent un minimum sérieuses et que l'appli ne vous explose à la g*****).

---

Il ne faut pas mettre tous les ORM dans le même panier.

Tous n'affichent pas les mêmes performances (cf posts précédents)

Je préconise l'écriture des requêtes en SQL dans les classes modèles

Cela permet:
1. De séparer et centraliser les requêtes (un des avantages du MVC)
2. Gagner en performances et en transparence (permet facilement de switcher vers des vues si nécessaire)
3. Identifier les paramètres des requêtes (plus facile à sécuriser)