Discussion :

[laffreuxthomas]

C'est bien mais papajoker a raison.

[anikon]

Par contre il faut préciser que zend db n'est pas un ORM.

[imikado]

C'est bien mais papajoker a raison.

Il faudrait développer un peu plus

@anikon Quand j'écris zendDb c'est un abus de langage, je parle de Zend_Db_Table_Abstract

[anikon]

Oui oui j'avais compris mais le module complet zend_db n'est pas un orm. C'est un composant pour coder proprement sa partie modele et s'affranchir de l'écriture de certaines requêtes SQL simple mais il n'y a aucun mapping objet.

[imikado]

D'ailleurs une chose fort dommage sur zendF 1.* c'est le fait qu'il ne génère pas la couche modèle: il ne fait que créer des classes vides à remplir soi-même
Je ne sais pas si cela a changé avec la branche 2

[papajoker]

C'est bien mais papajoker a raison.

Il faudrait développer un peu plus

J'ai posté 2 ou 3 fois sur le sujet imikado ! pas encore compris, j'ai des doutes.

ton code est ANTI orm
tu désynchronises tes objets des tables et tu oses parler de mapping objet derrière.

tu es marqué expert ici, et tu mets en exemple de code orm, LE code qu'il ne faut pas, il est normal de changer ton exemple ... ou si tu le laisses ... tu donnes l'exemple parfait pour que les débutants trébuchent.

ps: moi aussi je fais des bourdes, pas de probleme, mais il ne me faut pas 24heures pour le voir lorsque l'on me le dit.

[imikado]

Je réponds à chacun de vos posts, arguments et exemple de code à l'appui

Je ne comprends pas cette phrase:

ton code est ANTI orm
tu désynchronises tes objets des tables et tu oses parler de mapping objet derrière.

Vous avez une classe par table, vous regrouper l'ensemble des méthodes (et donc requetes) dans chacune des classe, pourquoi je "desynchronise" les objets des tables ?
Vous pouvez aussi bien manipuler un objet représentant votre enregistrement en base

Code :

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

1
2
3
4
 
$oArticle=model_article::getInstance()->findById(4);
$oArticle->monChamp="ma valeur";
$oArticle->save();

Que faire appel à une méthode plus optimal (plus performante) pour executer une procedure stoquee ou une simple requete UPDATE/DELETE ou autre

C'est plus flexible et basé sur les besoins que j'ai pu voir dans le monde pro, ou l'on veut toujours un subtil mélange de productivité (à coder) et de performances (d'ou la possibilité d'executer des requetes quand necessaires)

note: ce que je dit ici est autant valable avec l'ORM de Zend, yii que sur le mien

tu es marqué expert ici, et tu mets en exemple de code orm, LE code qu'il ne faut pas, il est normal de changer ton exemple ... ou si tu le laisses ... tu donnes l'exemple parfait pour que les débutants trébuchent.

Je ne comprends pas en quoi mon exemple est mauvais: comme dit plus haut on veut aussi bien pouvoir facilement manipuler des objets, qu'effectuer certaines actions performante: c'est ainsi sur des projets pro: tout n'est pas noir ou blanc

ps: moi aussi je fais des bourdes, pas de probleme, mais il ne me faut pas 24heures pour le voir lorsque l'on me le dit.

Je veux bien avouer avoir fait une bourde à partir du moment ou je comprends le problème

[imikado]

Je pense à une chose qui est peut-etre à l'origine d'un quiproquo:
dans mon ORM on a deux types de classes: model_maTable et row_maTable

model_maTable représente le "factory" execute les requetes et retourne des objets ou tableau d'objets row_maTable

row_maTable représente l'item "intelligent"

Les requetes UPDATE/DELETE, et les procedures stoquees sont des methodes dans la classe "factory"

[papajoker]

je te parle de exclusivement de :

Code :

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

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

ca fait 3..4 post (je radote ), j'insiste plus, sujet clos pour moi.

1 de mes post :

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]

je te parle de exclusivement de :



ca fait 3..4 post (je radote ), j'insiste plus, sujet clos pour moi.

1 de mes post :

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();          // !!!!!!!!!!

Effectivement on ne peut pas afficher nbVue sur la derniere ligne :il lui manquerait 1 (vu qu'il est incrementé avant)
et le save() ne sert à rien

C'est plutot:

Code php :

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

1
2
3
4
 
model_article::getInstance()->updateNbVue($id);
//ou
$oArticle->updateNbVue();

Je m'excuse si c'est cette ligne en erreur que vous souligniez

[papajoker]

non

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); // logiquement this->save() :)
}
}

je t'ai deja envoyé ce code !

dans ton code tu ne met PAS a jour $this->nbVue(et $this->id) LA EST L'ERREUR

tout ton modele est désynchronisé (this->nbVue est faux) de la bd

ca marche UNIQUEMENT si plus aucun traitement avec ton modele mais n'importe quel traitement sur ton modele conduit a la cata, merci l'orm.
Mais bon, la tu as une méthode exclusive qui me détruit mon objet et toute ma logique orm !

[imikado]

L'erreur est en amont: je me suis trompé dans l'exemple entre model et row ("factory" et "element")

Soit on met la methode dans le factory

Code php :

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

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

Et on peut l'appeler

Code php :

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

1
2
<?php
model_article::getInstance()->updateVueById(4);

Soit on crée une methode sur l'objet appelant le factory

Code php :

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

1
2
3
4
5
6
<?php
class row_article extends abstact_row{
 public methode updateVue(){
   model_article::getInstance()->updateVueById($this->id);
 }
}

Appelé ainsi

Code php :

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

1
2
3
4
<?php
$oArticle=model_article::getInstance()->findById(4);
//la methode retourne un objet de classe row_article
$oArticle->updateVue();

Soit on manipule l'objet directement

Code php :

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

1
2
3
4
<?php
$oArticle=model_article::getInstance()->findById(4);
$oArticle->nbVue=($oArticle->nbVue+1);
$oArticle->save();

[papajoker]

c'est ton framework, il n'y a que toi qui comprend

mais quand tu me mets en exemples a la fin :

Code :

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

$oArticle=model_article::getInstance()->findById(4);

//la methode retourne un objet de classe row_article
suis perdu row_article::getInstance()->findById(4); comprendrait mieux

Mais tu as peux être un problème(avec moi) de conception dans tes modèles :

il est surtout impossible avec un model de modifier la base sans toucher aux propriétés du modele.

exemple

Code :

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

1
2
3
4
5
6
7
8
 class Article extends Model{
   function increment($nb){
       $this->nombre+=$nb;
   }
   function inc($nb){
       $this->execute('UPDATE article SET nombre=nombre+? WHERE id='.$this->id,(int)$nb);
    }
 }

que vais je utiliser ?
inc() puis save() j'ai tout faut !!!
inc() seul OK
increment() seul FAUT !

Donc pour moi :
Avoir ce type de choix avec un model est une hérésie, j'ai une petite chance de m'en sortir uniquement si je ne quitte pas des yeux le code source de ma classe

par contre Model::getDB()->inc() la oui, je n'utilise pas le model mais la db donc c'est plus "normal" que je ne manipule pas les propriétés

[imikado]

mais quand tu me mets en exemples a la fin :
$oArticle=model_article::getInstance()->findById(4);
//la methode retourne un objet de classe row_article
suis perdu row_article::getInstance()->findById(4); comprendrait mieux

Oui mais non: on ne peut pas faire

Code :

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

row_article::getInstance()->findById(4)

J'explique : d'un coté on a la classe "factory" (model_) d'une table, par exemple article qui va contenir toutes les requetes findAll(), findListByCategorie() et autres methodes pour récuperer ses enregistrements

Ces méthodes retourne des tableaux d'objets "row" (row_) qui peuvent etre manipulée : on peut modifier des champs puis appeler la méthode save(), et ensuite libre à vous de rajouter des méthodes pour interagir, récupérer un objet d'une autre table...


Pour la partie "factory" / model_, vous ecrivez vous memes les différents methodes retournant les éléments, vous êtes donc au courant du fonctionnement de l'ORM pour votre projet

note: ce fonctionnement n'est pas exclusif à mon framework, ni à mon ORM vous pouvez faire de même sur les autres ORM (Zend framework, yii...)

[papajoker]

note: ce fonctionnement n'est pas exclusif à mon framework, ni à mon ORM vous pouvez faire de même sur les autres ORM (Zend framework, yii...)

tout à fait, je ne remet aucunement en cause ton Framework (ni aucun orm).

[TiranusKBX]

Personnellement j'ai écris une surcouche pour PDO ayant un comportement proche car les retour avec PDO ne me convenait pas

De ce fait mes requêtes maintenant me retourne directement des tableaux de données et plus des objets PDO quelque-peut embêtant à traiter.
De plus j'ai ainsi un traitement des erreurs simplifié, que du bénéfice !

Comme ma surcouche n'est pas lourde ça pompe très peut de ressource(à peine plus que PDO seul)

[zapkto]

Pourquoi n'avez-vous pas inclus l'orm de django dans vos tests ?

[imikado]

@zapkto je le répète ceci n'est pas un article benchmark, j'écrirais dès que possible un benchmark complet, parcontre je ne suis pas sur d'inclure django(python) ni ROR(ruby), ni hibernate(java) ni EntityFramework (.net) car je ne connais pas bien (pour ne pas dire du tout) ces langages

Après ce que je peux faire pour ce prochain article c'est ouvrir un topic pour demander aux developpeurs (vous) de me proposer les cas de benchmark manquant

[Aurélien LEQUOY]

ouai alors codé avec un ORM je ne vois pas comment cela peut etre plus rentable. Sachant que d'abord il faut former tout le monde ! Pour ma pars je fais beaucoup d'exotique et de query à la con alors le select simpliste est rarement ma tasse de thé. de plus faire des truc exotique avec un ORM ca demande une sérieuse d'apprentissage et c'est pas vraiment performant.

Après je ne vois pas comment du code ORM peut-être plus maintenant que du code SQL. sachant que le code SQL est quand même plus pérenne que du code ORM qui aura évolué entre les versions.

En principe c'est là qu'on me sors, oui mais tu peux changer de SGBD facilement !

Bin pour un client "grand compte" j'ai du passer de MySQL vers Oracle et cela à nécessité une semaine, certainement autant de temps que de refaire les quelques requêtes qui posaient problème... (c'était sous cakephp).

En parlant des perfs on oublie ...

Perso j'utilise juste une surcouche pour update / delete / insert (de faire en sorte que cela valide le modèle). plus une optionnel pour historiser les tables automatiquement si elles sont dans la liste des tables a historiser.