C'est bien mais papajoker a raison.
J'utilise l'ORM du framework
J'utilise un ORM particulier (précisez)
Je n'utilise pas d'ORM, j'utilise directement PDO/ODBC
J'ai écrit mon propre ORM
ORM késako ??
C'est bien mais papajoker a raison.
Par contre il faut préciser que zend db n'est pas un ORM.
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.
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
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.
Je réponds à chacun de vos posts, arguments et exemple de code à l'appui
Je ne comprends pas cette phrase:
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 ?Envoyé par papajoker
Vous pouvez aussi bien manipuler un objet représentant votre enregistrement en base
Que faire appel à une méthode plus optimal (plus performante) pour executer une procedure stoquee ou une simple requete UPDATE/DELETE ou autre
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();
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
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 blancEnvoyé par papajoker
Je veux bien avouer avoir fait une bourde à partir du moment ou je comprends le problèmeEnvoyé par papajoker
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"
je te parle de exclusivement de :
ca fait 3..4 post (je radote ), j'insiste plus, sujet clos pour moi.
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); } }
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:
Je m'excuse si c'est cette ligne en erreur que vous souligniez
Code php : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 model_article::getInstance()->updateNbVue($id); //ou $oArticle->updateNbVue();
non
je t'ai deja envoyé ce code !
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() :) } }
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 !
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
Et on peut l'appeler
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); } }
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
Appelé ainsi
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); } }
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();
c'est ton framework, il n'y a que toi qui comprend
mais quand tu me mets en exemples a la fin :
//la methode retourne un objet de classe row_article
Code : Sélectionner tout - Visualiser dans une fenêtre à part $oArticle=model_article::getInstance()->findById(4);
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
que vais je utiliser ?
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); } }
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
Oui mais non: on ne peut pas faireJ'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
Code : Sélectionner tout - Visualiser dans une fenêtre à part row_article::getInstance()->findById(4)
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...)
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)
Pourquoi n'avez-vous pas inclus l'orm de django dans vos tests ?
@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
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager