Discussion :

[laffreuxthomas]

Une base de données relationnelle est une collection de lignes de données dans des tables et non pas une collection d'objets instanciant des classes.

Un mapping objet sert à naviguer d'objet en objet. Chaque objet est chargé avec l'intégralité d'une ligne d'une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l'objet du mapping chargera toujours toutes les colonnes.

Par comparaison, le SQL sert à sélectionner les valeurs des cellules dont on a besoin et uniquement celles-là. Et ça tombe bien car il est rare d'avoir besoin simultanément de toutes les colonnes d'une table dans une même portion du programme.

En SQL nous effectuons des jointures afin de ramener en une requête telle cellule d'une table couplée à telle autre d'une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.

Certes les ORM proposent tous une solution paliative, une sorte de sous-SQL bridé, avec lequel il devient possible d'extraire des valeurs sans passer par les objets. Mais c'est de l'inversion des bonnes pratiques qu'il s'agit. Bien utiliser un ORM, c'est utiliser par défaut les objets du mapping et ne pratiquer le sous-SQL que dans des cas qui le justifient. Bien utiliser le SQL, c'est ne charger que les données dont on a besoin, systématiquement. Le débat ORM vs SQL porte non pas sur ce qu'on peut faire - on peut faire des objets et des tableaux avec un ORM autant qu'en SQL - mais quelles sont les bonnes pratiques en matière de base de données.

[laffreuxthomas]

Au-delà des considérations générales, il existe un impact négatif en PHP sur l'utilisation systématique d'objets. Selon moi cela suffit à changer de perspective par rapport à d'autres langages : les bonnes pratiques en PHP ne sont pas les mêmes que celles en Java. Le cœur de PHP est le tableau PHP. Et ça tombe bien car le SQL est fait pour ramener des tableaux. Alors pour la simplicité et la performance, restons-en à l'essentiel : le couple SQL-tableau PHP.

[Traroth2]

C'est ne pas penser à ceux qui au contraire ont une faible expérience en SQL (voir pas du tout) et qui seront surement plus à l'aise avec un ORM...

Ca me fait penser au débat ligne de commande/interface graphique

Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.

[Traroth2]

Je le répète les ORM permettent de saisir nos propres requêtes
Par exemple il nous est arrivé dans nos ORM d'appeler des procédures stoquées pour gagner en performance, mais aussi des vues et autres requetes plus complexe

Il est assez rare en entreprise de migrer le SGBD d'un projet on peut donc écrire sans trop s'inquiéter des requêtes en utilisant les avantages du SGBD choisi

Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.

[erwanlb]

Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.

C'est plus transparent dans un développement que d'y mettre des lignes SQL et une barda de lignes pour la connexion, etc...

Mais je connais pas HQL....

[erwanlb]

Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.

Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?

[imikado]

Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.

L'intérêt de l'ORM :
- organiser les requetes SQL (on groupe les requetes pas table/entité concerné)
- la flexibilité sur la manipulation (on recupere un objet, on met des champs à jour et on sauvegarde)
- on profite des avantages du MVC
- profitez du DRY *

*DRY : Don't Repeat Yourself. Par exemple une chose toute bête: vous souhaitez récupérer tous les articles d'un auteur donné.
Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code
L'avantage avec un ORM c'est ici, dans la classe de l'article vous allez ajouter une fois une requete recuperant les entrées d'un auteur passé en variable.
Vous pourrez l'appeler de n'importe ou à n'importe quel moment, et si pour une raison ou une autre il y a des changements à faire vous modifierez uniquement cette méthode

Une base de données relationnelle est une collection de lignes de données dans des tables et non pas une collection d'objets instanciant des classes.

Un mapping objet sert à naviguer d'objet en objet. Chaque objet est chargé avec l'intégralité d'une ligne d'une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l'objet du mapping chargera toujours toutes les colonnes.

Par comparaison, le SQL sert à sélectionner les valeurs des cellules dont on a besoin et uniquement celles-là. Et ça tombe bien car il est rare d'avoir besoin simultanément de toutes les colonnes d'une table dans une même portion du programme.

En SQL nous effectuons des jointures afin de ramener en une requête telle cellule d'une table couplée à telle autre d'une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.

Vous pouvez le faire aussi
Dans mes projets il m'arrive d'avoir besoin de joindre N tables.
Prenons par exemple une table lié à une catégorie et un auteur:
Vous avez le choix soit de faire appel à l'objet article et lui demander de vous retourner l'objet catégorie et auteur, soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
C'est souple un ORM : vous avez le choix

[laffreuxthomas]

Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code

Allons, la factorisation est dans la nature du bon programmeur. L'ORM est une factorisation automatisée, elle est loin d'être la plus élégante.

soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
C'est souple un ORM : vous avez le choix

Et si nous n'avons pas besoin de toutes les colonnes de la table Article ?

Alors il nous faudrait implémenter un objet Article "pauvre" qui aurait perdu des propriétés ?

C'est surement possible d'une manière ou d'une autre. Mais tout cela nous pouvons aussi le faire en utilisant SQL. D'où la conclusion de mon post : ce débat ne concerne pas ce qu'on peut faire, mais ce qu'il est mieux de faire.

[Traroth2]

Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?

Dans un système, toute couche ajoute de la complexité. On l'accepte à cause des services dont on bénéficie. Là, si on utilise Hibernate, mais qu'on fait tout en SQL quand même, je ne vois pas quel service rend l'ORM.

[Traroth2]

L'intérêt de l'ORM :
- organiser les requetes SQL (on groupe les requetes pas table/entité concerné)
- la flexibilité sur la manipulation (on recupere un objet, on met des champs à jour et on sauvegarde)
- on profite des avantages du MVC
- profitez du DRY *

*DRY : Don't Repeat Yourself. Par exemple une chose toute bête: vous souhaitez récupérer tous les articles d'un auteur donné.
Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code
L'avantage avec un ORM c'est ici, dans la classe de l'article vous allez ajouter une fois une requete recuperant les entrées d'un auteur passé en variable.
Vous pourrez l'appeler de n'importe ou à n'importe quel moment, et si pour une raison ou une autre il y a des changements à faire vous modifierez uniquement cette méthode



Vous pouvez le faire aussi
Dans mes projets il m'arrive d'avoir besoin de joindre N tables.
Prenons par exemple une table lié à une catégorie et un auteur:
Vous avez le choix soit de faire appel à l'objet article et lui demander de vous retourner l'objet catégorie et auteur, soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
C'est souple un ORM : vous avez le choix

Mais là, on ne parle pas d'ORM, alors, mais de framework de persistance. MyBatis fait tout ce que tu dis très bien, et n'a pas la complexité de Hibernate.

[laffreuxthomas]

Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?

Il y a de ça effectivement. Avec une différence. Le client final est l'utilisateur de l'interface graphique. Même s'il gagnerait en efficacité en se formant à la ligne de commande, c'est lui le roi, et c'est au programmeur d'adapter le logiciel. Le client d'un ORM est le développeur objet, il n'est pas un client final et n'est donc qu'un sous-roi : si son logiciel est moins efficace que celui de la concurrence, un jour cela se verra et il disparaitra.

L'ORM est une erreur conceptuelle. La conception d'un schéma d'une DB obéit à des règles qui n'ont rien à voir avec celles de la programmation à objets. Mieux vaut concevoir ses objets avec une approche "métier", je veux dire que les objets devraient être conçus en fonction de ce que le logiciel doit faire et non pas en fonction des règles de normalisation. C'est un peu comme si la boutique devait organiser ses étalages en fonction des rayons de son entrepôt. Mais les étalages devraient être gouvernés par le marketing alors que les entrepôts sont organisés par la logistique.

[imikado]

@laffreuxthomas Justement la factorisation est le propre de l'ORM, et les frameworks permettent de générer les diverses classes nécessaires

Et si nous n'avons pas besoin de toutes les colonnes de la table Article ?

Alors il nous faudrait implémenter un objet Article "pauvre" qui aurait perdu des propriétés ?

Non : faites une méthode différente
Dans les ORM on a souvent la notion de factory et d'item: d'un coté une classe modèle qui, via des méthodes nous retourne un tableau d'objet
De l'autre ces objets retournés peuvent être des classes riches (ou non si on veut plus de performance)

Ici vous pouvez avoir une méthode findAll() findByArticle() et findByArticleRich() (qui utiliserait des jointures)

[imikado]

Mais là, on ne parle pas d'ORM, alors, mais de framework de persistance. MyBatis fait tout ce que tu dis très bien, et n'a pas la complexité de Hibernate.

L'ORM du mkframework fonctionne ainsi
Je développe depuis une bonne dizaine d'année, comme je l'ai déjà dit j'ai développé en parallèle mon framework en utilisant symfony/propel puis Zend Framework et son Zend DB
J'ai essayé de faire un bon compromis entre un ORM confortable, flexible et performant
On a le choix entre utiliser des objets plus ou moins riche, parcontre je ne propose pas de méthodes pour bypasser le SQL, ici on écrit ses propres requetes SQL plus ou moins complexe

[laffreuxthomas]

Non : faites une méthode différente
Dans les ORM on a souvent la notion de factory et d'item: d'un coté une classe modèle qui, via des méthodes nous retourne un tableau d'objet
De l'autre ces objets retournés peuvent être des classes riches (ou non si on veut plus de performance)

L'ORM est donc plus compliqué que le SQL dès qu'on parle de performance.
CQFD.

Je ne vais pas répéter une troisième fois la conclusion.

[imikado]

Non c'est vous qui avez le choix: si vous misez sur les performances, utilisez (pour le mkf) les méthodes findManySimple() et findOneSimple()
Si vous n'avez pas à vous souciez des performances, vous pouvez utiliser les méthodes findMany() et findOne()
Si cela dépend des pages et des éléments à afficher, vous pouvez mixer les deux

Comme l'indique erwanlb les utilisateurs ne sont pas des chronomètres, mais comme nous le savons tous, certaines pages, fonctionnalités nécessitent d'afficher beaucoup d'élements, et à ce moment on est bien ravi de savoir que l'on peut miser sur les performances dans ce cas là

Exple objets riches

Code :

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

1
2
3
4
5
6
7
8
9
 
class  model_auteur extends abstact_model{
 
(...)
findArticleByAuteur($auteur_id){
 return $this->findMany('SELECT * from article WHERE auteur_id=?',(int)$id);
}
 
}

Exple objets léger (très rapide)

Code :

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

1
2
3
4
5
6
7
8
9
 
class  model_auteur extends abstact_model{
 
(...)
findArticleByAuteur($auteur_id){
 return $this->findManySimple('SELECT article.titre,auteur.nom from article INNER JOIN auteur on auteur.id=article.auteur_id WHERE auteur_id=?',(int)$id);
}
 
}

[laffreuxthomas]

En effet, et en SQL également vous avez le choix. Vous pouvez charger les données dans des objets complexes et mal pensés si vous tenez à détériorer les performances, par exemple parce que la page n'affiche qu'un seul élément. Vous pouvez au contraire écrire des objets faits pour ce que le logiciel doit faire et alors vous conserverez de bonnes performances.

[laffreuxthomas]

Exple objets léger (très rapide)

Code :

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

1
2
3
4
5
6
7
8
9
 
class  model_auteur extends abstact_model{
 
(...)
findArticleByAuteur($auteur_id){
 return $this->findManySimple('SELECT article.titre,auteur.nom from article INNER JOIN auteur on auteur.id=article.auteur_id WHERE auteur_id=?',(int)$id);
}
 
}

Merci pour le code. C'est effectivement une bonne idée, puisque si tout le monde voit bien à quoi ressemble l'utilisation de SQL via PDO (ou JDBC pour Traroth2 avec qui je suis bien entendu d'accord), ce n'est pas le cas pour les ORM. En tout cas en ce qui me concerne, mon expérience des ORM vient de Java alors qu'en PHP j'ai pu choisir et donc je n'ai jamais pratiqué.

Que renvoie la méthode "findArticleByAuteur" ? Si c'est un objet, eh bien à mon avis un tableau PHP est plus simple, plus élégant, plus performant qu'un objet écrit ad hoc pour le résultat d'une requête. [EDIT] Et si c'est un tableau, la méthode "findManySimple()" fait-elle un traitement particulier en plus d'un simple appel à PDO ?

[laffreuxthomas]

Une synthèse de mon point de vue ici.

[imikado]

Que renvoie la méthode "findArticleByAuteur" ? Si c'est un objet, eh bien à mon avis un tableau PHP est plus simple, plus élégant, plus performant qu'un objet écrit ad hoc pour le résultat d'une requête. [EDIT] Et si c'est un tableau, la méthode "findManySimple()" fait-elle un traitement particulier en plus d'un simple appel à PDO ?

findArticleByAuteur retourne un tableau d'objets
La différence entre findMany et findManySimple:
findManySimple fait un simple appel à pdo et retourne un tableau d'objets pdo (objet simple) mais tres rapide
findMany "hydrate": il fait une requete pdo et crée à partir du tableau retourné un tableau d'objets "riches" de classe row_maTable
Cela permet de l'enrichir de différentes méthodes et de permettre la manipulation
Exple:

Code php :

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

1
2
3
4
 
$oArticle=model_article::getInstance()->findById(2);
$oArticle->titre="mon titre";
$oArticle->save();

[imikado]

Une synthèse de mon point de vue ici.

Le problème c'est que vous écrivez des choses inexactes comme:

Chaque objet est chargé avec l’intégralité d’une ligne d’une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l’objet du mapping chargera toutes les colonnes.

Vous pouvez lors de votre requete en SQL indiquer les champs à récupérer par exemple

Code :

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

1
2
3
4
5
6
7
 
public function findAuteurNameById($id){
 return $this->findOne('SELECT auteur.nom from auteur WHERE id=?',(int)$id);
}
public function findListAuteurName(){
 return $this->findOne('SELECT auteur.nom from auteur');
}

Idem pour cette phrase

En SQL nous effectuons des jointures afin de ramener en une requête telles cellules d’une table couplées à telles autres d’une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.

Vous pouvez tres bien écrire vos jointure

Code :

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

1
2
3
4
 
public function findArticleWithAuteur($id){
 return $this->findOne('SELECT article.titre, auteur.nom from article INNER JOIN article.auteur_id=auteur.id AND article.id=?',(int)$id);
}