Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour !
voila, je me pose une question sur le modèle MVC.
un exemple concret :
un modèle :
- user
un controlleur
- user
une action :
- ajouter
donc ma question est-il préférable de
1/ créer une méthode ajout() dans mon modèle "user" qui sera appelé dans mon action "ajouter" du controlleur "user"
2/ dans mon controller faire :
$user = new User();
$user->insert($data);
merci de m'éclaircir de vos lumières
Dernière modification par Hotch (30-10-2008 12:13:19)
Hors ligne
Hello,
2 pour moi
A+
Hors ligne
bah je suis effectivement parti sur ce choix mais du coup mes models ne contiennent "que" les variables $_name, $_primary et les relations avec $_referenceMap
rien d'autre...
Hors ligne
Hello,
Moi y a même pas de variable ;-) .
<?php class Utilisateur extends Zend_Db_Table_Abstract {}
A+
Hors ligne
ok merci de vos réponses
Hors ligne
mikaelkael a écrit:
Hello,
2 pour moi
A+
J'avoue être un peu étonné par cette réponse.
Dans l'architecture MVC, les models contiennent essentiellement le code métier avec les accès aux bases, non ?
On y trouve donc les traitements bruts des données en assurant leur intégrité grâce aux transactions (commit, rollback) que j'utilise systématiquement pour les créations et mises à jour de plusieurs tables.
Mais bon, je ne suis pas non plus dogmatique...
Hors ligne
Hello,
Concernant les BDD, un Zend_Db_Table_Row_Abstract possède des hook (pre_insert et post-insert) donc si j'ai besoin je l'ai utilise mais je ne vois pas l'intérêt de créer une fonction ajout dans un modèle.
A+
Hors ligne
ni l'un ni l'autre
dans on model tu fait un UserTable et un User (ou UserRow)
UserTable est une classe dérivant de Zend_Db_Table et User est une classe dérivant de Zend_Db_Table_Raw
dans ton controller tu n'a plus qu'a faire
$user = $userTable->creatRow($myArrayFormData); $user->save();
mieux que ça lorsque tu prépare ton formulaire tu créé un usr que tu mets en session dans la cas d'un ajout ou un user que tu a pris dans la base en cas édition.
tu affiche ton formulaire avec les donnée de ton user
lorsque le formulaire est posté tu récupère les donnée et le user en session tu modifie le user et tu appelle save.
Zend_Db va alors faire seul un insert ou un update et dans le cas d'un update il ne fera le update que sur les donnée qui ont changées.
A+JYT
Hors ligne
Voui...
mais que ce soit pre_insert et post-insert ou create row, je ne comprends pas comment ces mécanismes peuvent rendre inutile le mécanisme des transactions...
Un exemple juste pour illustrer mon propos :
j'ai une BDD pour un concessionnaire automobile qui me gère dans des tables différentes :
le stock de voitures,
les clients,
les commandes de client,
les demandes de réapprovisionnement,
le suivi des ventes sur une marque
Donc 5 tables.
La concession fait une vente, la vente est donc saisie sur l'intranet ce qui entraîne les traitements suivants :
1) Retrait du véhicule vendu de la table 'stock de voiture'
2) Ajout d'une créance sur la table 'client' pour l'acheteur concerné
3) Enregistrement de la commande du client dans la table 'commandes'
4) Création d'un enregistrement de demande d'approvisionnement dans la table 'approvisionnement'
5) Ajout de la référence du modèle vendu dans la table 'marque' du véhicule
Si je ne fais pas d'ouverture de transaction sur la base et qu'à l'étape 3 il y a un problème on aura une base de données qui a un problème d'intégrité, sur laquelle il faudra intervenir, soit à la main (si le problème n'est apparu qu'une ou deux fois dans la journée et qu'il y a une bonne log capable d'identifier les données en cause) soit avec une moulinette si le problème est plus fréquent.
Alors que si je fais :
public function creation_vente($vente_data) { $this->_db->beginTransaction(); try { // Mise à jour des tables $this->_db->commit(); } catch (Exception $e) { $this->_db->rollBack(); // Les écritures partielles sont supprimées $this->logger->alert('Messqage d'erreur clair'); $this->dumptofile($vente_data); } }
Ma base garde son intégrité, car soit j'écris tout, soit rien et je garde les données problématiques au chaud pour analyser le problème.
L'exemple donné est un cas d'école, mais c'est concrètement les méthodes que j'utilise aussi dans des traitements batch sur mainframe ou une chaîne tourne pendant plus de 40 heures en écrivant des millions de lignes dans plusieurs centaines de tables d'un SGBD relationnel (DB2)
Mais maintenant que Mysql gère les transactions je ne vois ni pourquoi ni comment s'en passer.
Mais je suis un débutant sur le Zend Framework, et peut être que les mécanismes dont vous me parlez gèrent les transactions en arrière plan, c'est ça ?
(Si oui, pardon d'avoir été un peu long pour rien)
Hors ligne
Hello,
A vouloir répondre vite, je ne mets que des bêtises.
@Jean-Marc : effectivement quand ton exemple s'est présenté à moi (ou presque), j'ai fais comme toi. Je n'ai pas non plus trouvé d'autres manières de faire .
@sekaijin : tu as tout à fait raison, c'est ce que je fais aussi (createRow() + insert())
Ma réponse initiale était destinée à éviter la création d'une méthode ajout dans un model lié à une table de BDD.
Donc pour résumer, dans la majeure partie des cas, j'utilise la méthode de sekaijin et pour le cas des transactions, j'utilise la méthode de Jean-Marc.
En espérant ne pas vous avoir trop embrouillé
A+
Hors ligne
Non pas de problème Mikaelkael,
Je suis un éternel angoissé de ne pas être capable de suivre les évolutions successives qu'imposent le développement.
Je te laisse imaginer le saut conceptuel que représente le début d'un apprentissage pour encoder son programme sur des cartes 80 ou 96 colonnes vers la maîtrise nécessaire, et si enrichissante, du développement objet...
(avec quelques étapes entre les deux, heureusement)
Donc le PHP, le HTTP, Ajax et autre, tout ça dans le ZF sont encore assez neufs pour moi, et il est facile de me faire douter.
J'ai donc cru que décidément je ne comprenais rien au ZF...
Cordialement.
Hors ligne
Pages: 1