Discussion :

[laffreuxthomas]

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

Alors "findManySimple" c'est PDO (SQL) tandis que "findMany" est l'ORM. Décidément, vous ne comprenez pas ce que je raconte. Oui un ORM permet de faire du SQL (ou du moins un sous-ensemble, le HQL de Hibernate par exemple est bridé). On le peut mais ça ne sert pas à ça. Ce SQL sort du mapping d'objets. Quel est l'intérêt de votre ORM si vous n'utilisez que "findManySimple" comme le cas subit par Traroth2 ? Aucun. L'intérêt d'un ORM c'est l'ORM c-à-d. les objets.

Pour HQL il me semble qu'il est parsé ce qui permet générer des dialectes SQL dans différents SGBD. Cela avait une utilité à l'époque de Oracle 8 et de ses jointures externes spécifiques dans la clause WHERE. Maintenant ce genre de besoin est périmé, pour faire du multi-SGBD mieux vaut s'en tenir à SQL 92 que tout le monde implémente.

[papajoker]

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.

La il faut fournir le nom du coupable, normalement tous les orm sont relativement intelligents, il fournissent pour des requetes normales (a 90%) du bon code sql (sauf recuperation par défaut de toute la ligne, mais paramétrable)

Un orm (mais pas le seul) qui n'a aucun probleme de jointure (meme avec tables pivots)
ma source : Eloguent orm php :
https://github.com/laravel-france/la...#eager-loading

[imikado]

Alors "findManySimple" c'est PDO (SQL) tandis que "findMany" est l'ORM. Décidément, vous ne comprenez pas ce que je raconte. Oui un ORM permet de faire du SQL (ou du moins un sous-ensemble, le HQL de Hibernate par exemple est bridé). On le peut mais ça ne sert pas à ça. Ce SQL sort du mapping d'objets. Quel est l'intérêt de votre ORM si vous n'utilisez que "findManySimple" comme le cas subit par Traroth2 ? Aucun. L'intérêt d'un ORM c'est l'ORM c-à-d. les objets.

La vie n'est pas binaire, le developpemente non plus, j'ai rajouté une partie à l'article

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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

[papajoker]

@imikado

Tu es pour les orm ok
Mais tu nous parles (ventes) que ton ORM

j'ai développé en parallèle mon framework en utilisant symfony/propel puis Zend Framework et son Zend DB

Pourquoi tu ne parles pas de propel / Zend DB ? ton message serait 300 fois plus crédible.

Revenir a tout moment a ton code, me donne l'impression d'être dans le sujet "ORM de imikado or not ORM, faut-il l'utiliser ?" du coup pas de débat possible

[imikado]

Je suis désolé de donner des exemples uniquement avec mon ORM mais effectivement, on peut faire de même avec Doctrine ou Zend DB ou même Yii

Comme je le dit dans l'article j'utilise la syntaxe de mon ORM pour le billet, mais ces exemples sont valable pour d'autres

La syntaxe est juste différente

[Tsilefy]

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.

Comparer un tableau et un objet, ou utiliser l'un à la place de l'autre consiste à mélanger deux paradigmes complètement différents, que ce soit en PHP ou ailleurs. Un objet n'est pas un vulgaire conteneur à données, c'est une entité avec des données et des méthodes pour manipuler ces objets et accomplir un résultat. A chacun sa fonction et son utilité, ça n'a rien avoir avec les bonnes pratiques PHp, mais avec la bonne pratique de programmation en général.

[Tsilefy]

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.

Le principe de l'ORM n'est-ce pas justement de disposer d'objets métiers découplés de la source de données?

[laffreuxthomas]

@imikado : Dans votre article, la requête UPDATE article SET nbVue=nbVue+1 WHERE id=? . Encore un bon exemple de défaut de performance de l'ORM. Avec le mapping vous passez par un SELECT, vous avez donc un aller-retour inutile des données, et en plus si vous n'êtes pas safe au niveau multi-threads car lorsque votre PHP s'exécutera plusieurs fois simultanément vous perdrez des vues.

La il faut fournir le nom du coupable, normalement tous les orm sont relativement intelligents, il fournissent pour des requetes normales (a 90%) du bon code sql (sauf recuperation par défaut de toute la ligne, mais paramétrable)

Un orm (mais pas le seul) qui n'a aucun probleme de jointure (meme avec tables pivots)
ma source : Eloguent orm php :
https://github.com/laravel-france/la...#eager-loading

Mmh. Oui c'est vrai.

Comparer un tableau et un objet, ou utiliser l'un à la place de l'autre consiste à mélanger deux paradigmes complètement différents, que ce soit en PHP ou ailleurs. Un objet n'est pas un vulgaire conteneur à données, c'est une entité avec des données et des méthodes pour manipuler ces objets et accomplir un résultat. A chacun sa fonction et son utilité, ça n'a rien avoir avec les bonnes pratiques PHp, mais avec la bonne pratique de programmation en général.

Non. On ne programme pas en PHP comme on programme en Java. Et en JavaScript on programme encore différemment. En revanche on programme en Java comme en C# ou même en C++. Je ne parle pas de la syntaxe ou des techniques (nettoyage de mémoire ou autre) mais de la manière de penser.

Le principe de l'ORM n'est-ce pas justement de disposer d'objets métiers découplés de la source de données?

On n'appelle pas ça "mapping" pour rien. C'est la structure qui est couplée. Pas le type du SGBD qui effectivement se retrouve un peu découplé.

[laffreuxthomas]

La il faut fournir le nom du coupable, normalement tous les orm sont relativement intelligents, il fournissent pour des requetes normales (a 90%) du bon code sql (sauf recuperation par défaut de toute la ligne, mais paramétrable)

C'est juste. Le projet sur lequel j'ai utilisé EclipseLink (une architecture REST couplée avec un ORM) ne permettait d'utiliser ces capacités et je les ai oubliées. Que la honte soit sur moi.

Le fond n'est pas changé : avec un ORM il faut travailler plus qu'avec du SQL dès que l'on parle de performance. => Lorsqu'on utiliser un ORM, la performance n'est plus le but à atteindre (comme en SQL) mais un éventuel problème qu'on ne traite que lorsqu'il devient insupportable.

[imikado]

@imikado : Dans votre article, la requête 'UPDATE article SET nbVue=nbVue+1 WHERE id=?' . Encore un bon exemple de défaut de performance de l'ORM. Avec le mapping vous passez par un SELECT, vous avez donc un aller-retour inutile des données, et en plus si vous n'êtes pas safe au niveau multi-threads car lorsque votre PHP s'exécutera plusieurs fois simultanément vous perdrez des vues.

Je n'ai pas bien compris: vous pouvez faire une méthode qui execute juste un select, pourquoi me parlez vous d'aller retour ? c'est juste une requete SQL

[papajoker]

@imikado

Code sql :

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

SET nbVue=nbVue+1

normalement c'est

Code :

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

set nbVue= . $this->nbVue++ ...

j'injecte les datas du modele !
toi tu lis dans la db nbVue et tu l'incremente, pas utilisé ton modele(objet) !
et je ne parle pas de la propriété nbVue de ton objet ...

[imikado]

Pourquoi s'embeter et faire un select puis un update: pour incrementer un champ autant le demander directement en SQL pure

[papajoker]

avais pas vu c'est dans le blog pour id meme punition

Code :

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

1
2
3
4
5
6
7
class model_article extends abstract_model{
(…)
public function updateNbVue(){
$this->nbVue = $this->nbVue+1;
$this->execute(‘UPDATE article SET nbVue=? WHERE id=?’,$this->nbVue,$this->id);
}
}

[laffreuxthomas]

Pourquoi s'embeter et faire un select puis un update: pour incrementer un champ autant le demander directement en SQL pure

Pour le coup je suis d'accord. C'est le passage par le mapping avec "$oArticle->nbVue=($oArticle->nbVue+1);" auquel je reprochais de charger via un SELECT préalable. Dans un cas pareil mieux vaut ne pas passer par le modèle.

[imikado]

avais pas vu c'est dans le blog pour id meme punition

Code :

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

1
2
3
4
5
6
7
class model_article extends abstract_model{
(…)
public function updateNbVue(){
$this->nbVue = $this->nbVue+1;
$this->execute(‘UPDATE article SET nbVue=? WHERE id=?’,$this->nbVue,$this->id);
}
}

Oui mais on a le choix entre faire ceci ou

Code :

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

1
2
3
4
5
6
 
class model_article extends abstract_model{
 public function updateNbVueById($id){
  $this->execute('UPDATE article SET nbVue=nvVue+1 WHERE id=?',$id);
 }
}

[papajoker]

laffreuxthomas
oui, mais son code est pour montrer utilisation de l'orm !

@imikado
et passer l'id dans la méthode du modèle !!!!!!!!!!!!!!! tu recupères un objet de ta base et tu utilise le meme objet pour modifier un autre champ ! qui si lui meme est chargé en objet : tout ton mapping est cassé

tu trouves ca normal imikado de se retrouver avec des objets qui ne reflètent pas exactement ta db ?

Code :

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

1
2
3
4
5
6
7
8
9
10
$oArticle=model_Article::getInstance()->findById($id);
$oArticle->titre=$titre;
$oArticle->save();
//ou
$oArticle->nbVue=($oArticle->nbVue+1);
$oArticle->save();
 
$oArticle->updateNbVue($id);
echo $oArticle->nbVue ; // !!!!!!!!!!!! FAUX
$oArticle->save();          // !!!!!!!!!!

[imikado]

Pour le coup je suis d'accord. C'est le passage par le mapping avec "$oArticle->nbVue=($oArticle->nbVue+1);" auquel je reprochais de charger via un SELECT préalable. Dans un cas pareil mieux vaut ne pas passer par le modèle.

Oui mais c'était pour dire que techniquement c'était possible
Pour indiquer le confort de travailler avec des objets, apres pour les perfs, voir mon précédent post (au dessus)

[laffreuxthomas]

laffreuxthomas
oui, mais son code est pour montrer utilisation de l'orm !

Exact.

@imikado
et passer l'id dans la méthode du modèle !!!!!!!!!!!!!!! tu recupères un objet de ta base et tu utilise le meme objet pour modifier un autre champ ! qui si lui meme est chargé en objet : tout ton mapping est cassé

tu trouves ca normal imikado de se retrouver avec des objets qui ne reflètent pas exactement ta db ?

C'est juste.
Son ORM est un peu jeune on va dire.
On reparlera de ses performances extraordinaires lorsqu'il aura pris de la bouteille.

[imikado]

Son ORM est un peu jeune on va dire.
On reparlera de ses performances extraordinaires lorsqu'il aura pris de la bouteille.

Cette version du framework/ORM date tout de même de 2009 (date d'hébergement par dvp) il ne sera plus "jeune" quand ? Zf2 et sf2 sont plus jeune que ma version 4

[imikado]

En 2007-2008 lorsque j'en etait à la version 2-3, j'avais un ORM plus lourd
http://forum.macbidouille.com/lofive...p/t217254.html
qui permettait d'écrire ceci dans la classe modèle

Code php :

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

1
2
3
4
5
6
7
8
9
 
Class Commande{
 
//(...)
 
public function init(){
    //une commande a un client dont id est egal a client_id
    $this->hasOne('Client')->dont('id')->egal('client_id');
}

Et qui permettait ceci

Code php :

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

1
2
3
echo $commande->recupClient()->nom;
    //ou 
    echo $commande->findParentClient()->nom;

Note: pour information je ne suis pas un jeunot, ne vous y trompez pas à cause de mon avatar
C'est celui de mon site de prévention