Discussion :

[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 ?

[imikado]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Pomalaix]

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

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

[imikado]

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

[erwanlb]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[erwanlb]

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

[imikado]

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

[erwanlb]

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

[Xinu2010]

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.

[_skip]

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.

[hotcryx]

Première fois que j'entends parler d'ORM

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

Rem: .net developer

[erwanlb]

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

[scandinave]

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

[Xinu2010]

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.

[erwanlb]

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

[imikado]

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

[javan00b]

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

[pcaboche]

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

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

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.

[rawsrc]

@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 idée de groupe : les informaticiens anonymes

[imikado]

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)