« ORM or not ORM » :
Faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ?

Le , par imikado, Rédacteur
Et vous les ORM ?
Avec l’arrivée des frameworks php, nous avons appris à évoluer entre ces nouveaux acronymes: MVC, DAO, DRY et ORM
Mais qu’est-ce qu’un ORM ?
Un ORM (Object Relation Mapping) est un ensemble de librairies qui vous permettent d’interagir avec vos données via des objets.
La plupart des frameworks respectant le design MVC* intègrent leurs propres ORM plus ou moins performants.
note: pour les exemples de syntaxes d’ORM j’utiliserai l’ORM du mkFramework.

*MVC: Model View Controller (séparation de la couche modèle de l’affichage et du contrôleur)

Un ORM pourquoi faire ?
Pourquoi utiliser un ORM plutôt que d’écrire simplement des requêtes SQL dans pdo ?
Si vous voulez coder propre, vous allez dans un premier temps écrire toutes vos requêtes dans un fichier php.
Si vous souhaitez organiser un peu mieux, vous allez regrouper les requêtes par table…
Si vous souhaitez éviter de vous répéter, vous aller créer un fichier/une classe pour les éléments récurrents (connexion, requête…) : principe de DRY*
Le fait de faire ceci, vous avez créé un pseudo début d’ORM

*DRY Don’t Repeat Yourself (créer des fonctions/classes pour éviter d’écrire plusieurs fois le même code)

Un des avantages des ORM se situe concernant la manipulation des données.
Prenons un exemple ou dans plusieurs pages vous devez modifier uniquement le titre, l’auteur ou le nombre de vues d’un article.
En pdo simple vous écririez:
Code : Sélectionner tout
1
2
3
‘UPDATE article SET titre=? WHERE id=?’,$titre,$îd 
‘UPDATE article SET auteur=? WHERE id=?’,$auteur,$îd 
‘UPDATE article SET nbVue=nbVue+1 WHERE id=?’,$îd
Avec l’ORM vous n’avez pas besoin d’écrire à l’avance vos différents types de requêtes
Code php : Sélectionner tout
1
2
3
4
5
6
7
8
9
$oArticle=model_Article::getInstance()->findById($id); 
$oArticle->titre=$titre; 
$oArticle->save(); 
//ou 
$oArticle->auteur=$auteur; 
$oArticle->save(); 
//ou 
$oArticle->nbVue=($oArticle->nbVue+1); 
$oArticle->save();
note: vous pouvez, si vous le souhaitez écrire des requêtes update
Exemple:
Code php : Sélectionner tout
1
2
3
4
5
6
class model_article extends abstract_model{ 
() 
public function updateNbVue($id){ 
$this->execute(‘UPDATE article SET nbVue=nbVue+1 WHERE id=?’,$id); 
} 
}
Les avantages sont multiples:
  • Organiser vos requêtes
  • Gagner du temps à l’écriture
  • Bénéficier des avantages du design MVC*


Tous les ORMs n’offrent pas les mêmes performances
Pour argumenter un post dans un topic sur ce même site, j’avais à l’époque procédé au benchmark suivant:
100 000 enregistrements en base de données mysql, et l’affichage de ces lignes dans un tableau HTML.
5 types différents:
- PHP simple en utilisant pdo
- une application en Zend Framework (version 1.11.12)
- une application en Yii (version yii-1.1.14)
- une application en MkFramework (méthode findMany() )
- une application en MkFramework en utilisant la récupération rapide (méthode findManySimple() )

Résultat des courses:
- 0.50s : pdo simple
- 0.58s : MkFramework en utilisant la récupération rapide
- 0.68s : Yii (version yii-1.1.14)
- 1.97s : MkFramework (normal)
- 11.20s : Zend Framework (version 1.11.12):

note : j’ai fait un benchmark sur 100 000 entrées pour avoir un volume assez important pour mettre en évidence les différences de performances, si j’avais fait un findById(4)
Sur un seul enregistrement on a
- 0.007s : pdo simple
- 0.015s : MkFramework en utilisant la récupération rapide
- 0.043s : MkFramework (normal)
- 0.049s : Zend Framework

note 2 pour obtenir de bonnes performances avez yii j’ai écrit les requêtes sans passer par les classes « ORM »
Code php : Sélectionner tout
1
2
3
4
$sql=’SELECT * FROM Article’; 
$connection=Yii::app()->db; // vous devez avoir une connection « db » 
$command=$connection->createCommand($sql); 
$articles=$rows=$command->queryAll();
note 2: j’ai fait un benchmark sur 100 000 entrées pour avoir un volume assez important pour mettre en évidence les différences de performances, si j’avais fait un findById(4)

Les ORMs offrent de la flexibilité
J’ai lu à plusieurs reprise que les ORM étaint lourd, qu’ils retournaient toujours toutes les colonnes même ceux non utilisées, que pour faire une jointure on se retrouvait à récupérer une ligne entière sur les deux tables liés…
Premièrement, vous pouvez choisir de récupérer uniquement certains champs de votre table. Beaucoup d’ORM proposent d’écrire sa requête SQL
Par exemple:

Code php : Sélectionner tout
1
2
3
4
5
6
class model_article extends abstract_model{ 
() 
public function findListAuteurName(){ 
return $this->findMany(‘SELECT auteur.name FROM auteur’); 
} 
}

Idem pour les fameuses jointures, vous avez le choix de récupérer par exemple un objet article puis de lui demander de nous retourner son auteur pour afficher son nom ainsi

Code php : Sélectionner tout
1
2
$oArticle=model_article::getInstance()->findById(4); 
print $oArticle->findAuteur()->nom;

Mais vous pouvez également écrire une méthode qui vous retournera les articles avec leur auteurs

Code php : Sélectionner tout
1
2
3
4
5
6
class model_article extends abstract_model{ 
() 
public function findArticleWithAuteur(){ 
return $this->findOne(‘SELECT article.titre, auteur.name FROM article INNER JOIN auteur ON article.auteur_id=auteur.id WHERE article.id=?’,(int)$id); 
} 
}

Une flexibilité aussi concernant les performances: selon les parties de vos sites vous avez besoin de récupérer plus ou moins d’élements et ceci plus ou moins rapidement.
La encore vous avez le choix: si vous devez récupérer un auteur, ses articles et ceci sans trop regarder les performances vous pouvez utiliser la méthode de récupération d’objets riches findMany/findOne
Si au contraire vous souhaitez afficher un bon nombre d’article d’auteurs, ou autre, vous pouvez utiliser la méthode rapide retournant des objets « simple » findManySimple/findOneSimple

Vous avez le choix

Conclusion
Comme vous avez pu le lire ici, tous les ORM ne sont pas des usines à gaz, ils sont très pratiques et vous permettent dans l’esprit du MVC de bien organiser votre couche modèle.
Les ORM sont une bonne chose que vous codiez une petite application ou une application importante: l’essentiel c’est de penser à long terme (la maintenabilité).
Il sera plus simple pour vous ou un collègue d’intervenir sur votre application avec ORM que sans ORM
Certains ORM sont plus ou moins flexible et performants comme les frameworks, mais ne les mettez pas tous dans le même panier, essayez en plusieurs avant de vous faire un avis.

note: je n’ai pas inclus Symfony 2 (pour tester doctrine) dans le benchmark, car malgré mes efforts d’optimisation de cache, mode production… je n’arrivais pas à passer sous la barre des 23 secondes
Si vous pouvez m’envoyer un exemple d’application affichant ces 100 000 enregistrements en moins de 2 secondes je suis preneur

note2: retrouvez dans mon post d’origine les éléments du benchmark (sauf celui de yii fait ici pour l’occasion)
http://www.developpez.net/forums/d12...u/#post6847792

Le billet: http://blog.developpez.com/ducodeetd...l-les-utiliser

Ci-joint les fichiers logs complets (réalisé via la commande time et wget 10 fois de suite)

Et vous ? utilisez vous un ORM si oui lequel ?
Si non qu'utilisez vous ? pdo ? odbc ? fonction spéciale (mysql_connect, myqli,oci_connect...)


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


 Poster une réponse Signaler un problème

Avatar de Tsilefy Tsilefy - Membre émérite https://www.developpez.com
le 11/09/2013 à 0:32
J'utilise Doctrine quand je fais de l'objet, et PDO pour le reste.

Par curiosité, est-ce que tu as pensé à faire un benchmark avec le même framework, mais en utilisant différents ORMs? Cela permettrait de mieux isoler les performances de chaque ORM de la "lourdeur" inhérente à chaque framework.
Avatar de imikado imikado - Rédacteur https://www.developpez.com
le 11/09/2013 à 0:37
Non j'avoue ne pas avoir "isoler" les performances de l'ORM en lui-même: utilisant leur propre ORM je ne sais pas si on peut les croiser

Sinon Doctrine est un bon ORM, je ne l'ai pas inclus dans ce billet qui parle plus des ORM des frameworks: sur leur site je n'ai pas réussi à reproduire un exemple réel d'ORM juste de la DAO (retournant un fetch de pdo )

C'est pour cela d'ailleurs que pour le mkframework il y a deux logs: un en mode simple (retournant des objets stdclass : plus DAO) et l'autre retournant un vrai objet ORM pour pouvoir bien comparer à ZF
Mais pour yii (ne le connaissant que très peu) j'ai eu du mal à avoir le même cas, obligé d'écrire en "DAO" la requête
En passant pas le générateur de CRUD il me pondait un objet activeRecord un peu obscur affichant une pagination (perte d'intérêt du benchmark ici...)
Avatar de rasta tom rasta tom - Futur Membre du Club https://www.developpez.com
le 11/09/2013 à 14:30
Dommage que le bench ne compare pas les même choses, ni les bonnes choses !!

D'une avec un ORM c'est vraiment un non sens de récupérer 100 000 objets, l'ORM va récupérer les données depuis la BDD puis "remplir" 100 000 objets correspondants, forcément ça créer une charge supplémentaire très importante par rapport à un pdo classique !! Ce n'est vraiment pas un scénario réaliste donc ca n'apporte pas grand chose pour quelqu'un qui voudrait faire un choix à partir de ces données de test. En général pour ce genre de cas les ORM propose des modes qui permettent de s'affranchir de cette phase de "remplissage" et de gagner beaucoup en perf !

Ensuite pour Yii ne pas utiliser les classes d'ORM ça ne sert juste à rien puisque le but est d'évaluer l'ORM. Pour le test donnée c'est équivalent à du pdo simple avec une légère surcharge pour les classes de connections et d’exécution de la requête. C'est un peu comme si on faisait un bench de framework pour le rendu d'1 fichier html statique

Enfin comme noté par Tsilefy, avec ce bench je peux prendre le meilleur ORM du monde et le mettre dans un framework tout pourri et les résultats seront mauvais alors que peut etre l'ORM en lui même est excellent
Avatar de imikado imikado - Rédacteur https://www.developpez.com
le 11/09/2013 à 14:38
Citation Envoyé par rasta tom

D'une avec un ORM c'est vraiment un non sens de récupérer 100 000 objets, l'ORM va récupérer les données depuis la BDD puis "remplir" 100 000 objets correspondants, forcément ça créer une charge supplémentaire très importante par rapport à un pdo classique !! Ce n'est vraiment pas un scénario réaliste donc ca n'apporte pas grand chose pour quelqu'un qui voudrait faire un choix à partir de ces données de test. En général pour ce genre de cas les ORM propose des modes qui permettent de s'affranchir de cette phase de "remplissage" et de gagner beaucoup en perf !
Oui c'est un test simple avec beaucoup d'enregistrements qui permet de mettre en evidence la perte du à cet aspect d'objets intelligents.
On peut ainsi voir la différence de performance sur une requete simple
Après comme vous le dites, certains frameworks permettent de récupérer de manière plus rapide des enregistrements (c'est le cas avec yii et le mkf en mode rapide)

Citation Envoyé par rasta tom
Ensuite pour Yii ne pas utiliser les classes d'ORM ça ne sert juste à rien puisque le but est d'évaluer l'ORM. Pour le test donnée c'est équivalent à du pdo simple avec une légère surcharge pour les classes de connections et d’exécution de la requête. C'est un peu comme si on faisait un bench de framework pour le rendu d'1 fichier html statique
Pour yii comme je le disais je n'ai pas trouvé comment récupérer des objets riches, je n'ai trouvé via le crud que comment récupérer cet objet "active record" qui m'affichait de manière paginé les enregistrements (perte d'interet s ici)
Et pour Zend Framework on voit une sacré différence de performance (et je n'affiche pas ici la différence de mémoire utilisée)

Citation Envoyé par rasta tom
Enfin comme noté par Tsilefy, avec ce bench je peux prendre le meilleur ORM du monde et le mettre dans un framework tout pourri et les résultats seront mauvais alors que peut etre l'ORM en lui même est excellent
Comme je l'ai dit plus haut, je compare des ORM de frameworks donc c'est normal de faire ainsi, après j'aurais bien aimé inclure SF2 avec doctrine mais cf mon explication je n'arrivais pas à des performances raisonnable
Que j'associe plus à ma méconnaissance du SF2 (et de son paramétrage)
Avatar de buxbux buxbux - Membre averti https://www.developpez.com
le 11/09/2013 à 15:18
Certes les ORM ralentissent l’exécution du code, cependant il faut les utiliser a bon escient. C'est a dire dans des projets ou ajouter un niveau d'abstraction a du sens.

Un projet avec plusieurs dizaines d'entités et de relations entre-elles ne se portera que mieux avec un ORM même si ils sont lourd.

Reste ensuite a utiliser les ORM correctement, sinon on se retrouve avec des charge monstrueuses oui. Par contre, bien utilisé on gagne de très nombreuses heures en maintenabilité et évolutivité...
Avatar de imikado imikado - Rédacteur https://www.developpez.com
le 11/09/2013 à 15:24

Il faut toujours faire la balance entre la perte de performance d'un coté et le gain de confort tant à la création qu'à la maintenabilité
Avatar de tontonnux tontonnux - Membre expérimenté https://www.developpez.com
le 11/09/2013 à 17:06
J'utilise Doctrine puisque je travaille avec Symfony.
L'ORM apporte un confort dont j'aurai du mal à me passer dans l'absolue. Maintenant, c'est vrai qu'il peut être à l'origine de certaines lourdeurs. Cependant, mon expérience tend à montrer que ces situations représentent presque toujours des cas dans lequel l'ORM n'est pas aussi indispensable.
Aussi, je pense qu'utiliser un ORM dans un projet objet est une bonne chose, mais il ne faut pas s'abstenir de coupler son usage avec du PDO selon le besoin.

En clair, il n'y a pas de ORM VS PDO, mais une bonne utilisation des deux selon le besoin.
Avatar de martin.magakian martin.magakian - Futur Membre du Club https://www.developpez.com
le 11/09/2013 à 18:31
Difficile à dire comme souvent avec ce genre de question.
Il y a les pour et les contre.

L'ORM oui! Mais lorsqu'il s'agit d'une application entreprise. Que les performance ne soit pas impérative. Que le nombre de QPS reste faible.
Quand le temps que me fait gagner l'ORM est supérieur au temps perdu par mes client pour cause d'ORM.

l'ORM, j'adore. C'est magique. Mais j'y vois deux problème major:
- Une logique simple ce traduit souvent pas énormément de requêtes simplissime. ENORMEMENT de requêtes simplissime.
- Cette technique camoufle trop la logique interne. L'abstraction fait gagner un temps précieux. Mais lorsque il faut optimiser un requête ou comprendre un bug, le temps gagner grâce à l'ORM est perdu. On ce retrouve à faire des hack monstrueux.

Les ORM sont trop souvent choisis en espérant avoir quelque chose de simple, de plus rapide à developer sans trop dégrader les performance.
- Simple: Oui, oui, oui !
- Rapide à développer: oui si on n'en fait pas une utilisation exotique.
- performant: non, non, non (ou à grand coup de hack)

Deux axes d'amélioration:
- Utiliser une BDD NoSQL de type document oriented tel que CouchDB ou MongoDB.
En gérant les entités on fait des read/save/update/delete d'une seul coup. Le travail de l'ORM est largement simplifier.

- Faire du ORM semi-manager type "SQL mapping framework". CAD écrire les requêtes SQL et définir un mappaging en objet. Avoir la main sur les requêtes permet d'améliorer les performance et évite les requettes "idiote" des ORM.
Exemple: mybatis (Java), Soma (C#) ...

Martin Magakian
Avatar de keke_ben keke_ben - Membre à l'essai https://www.developpez.com
le 11/09/2013 à 18:35
Dans l'environnement .net ce ne sont pas les ORM qui manquent : http://en.wikipedia.org/wiki/List_of...pping_software

J'utilise petaPoco pour les projets simple et courts, EF pour les petits projets, un peu de LinqToSQL pour certains clients, et un fait maison sur quelques projets particuliers.

Côté perf effectivement les ORM sont souvent inégaux : voir ici.

Ensuite je pense sincèrement que c'est une très bonne technologie, mais pas la réponse à tout (perdre la main sur le SQL n'est jamais une bonne chose) et surtout qu'un ORM ne peut pas répondre à tous les besoins ; ils ont des spécialités.
Avatar de Tsilefy Tsilefy - Membre émérite https://www.developpez.com
le 11/09/2013 à 19:29
Alternative aux axes d'amélioration de Martin: utiliser des caches, ajouter de la RAM et augmenter le nombre de CPU.

Évidemment ça varie selon les projets, mais entre le coût de la RAM et des CPUs supplémentaires et le coût du développement et de la maintenance hors ORM, ajouter du matériel peut être plus intéressant.
Contacter le responsable de la rubrique PHP