2
juin
2009
Atelier Zend Framework : Donnez de la puissance à vos modèles
juin
2009
Un article de doctorrock
4 Commentaires
Dans un modèle MVC, on a tendance à en demander trop aux contrôleurs. Ceux-ci doivent faire quelques lignes seulement, or on retrouve souvent des responsabilités qui leur sont attribuées à tort : Création des modèles et création des formulaires notamment. Nous allons voir ici comment donner vie à un modèle, et comment décharger le contrôleur tout en simplifiant son API.
L’atelier est là
Comme d’habitude, quelques idées de personnalisation du ZendFramework, qui sont à débattre sur le forum
4 Commentaires + Ajouter un commentaire
Commentaires récents
Archives
- novembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
- mars 2007
- février 2007
Très bon article comme toujours. En revanche j’ai du mal à appréhender la répartition de ton code
Bonjour,
je dois réoudre un probleme sur une application que je dois coder sous zend framework, une application en apparence il s’agit essentiellement de faire de la saisie de données afin de générer des statistiques. Et donc pour cela on a différentes tables qui sont reliées en général à un formulaire qui va récolter les informations nécessaire pour les insérer dans cette table.
Le petit piège sur ce projet c’est que les utilisateurs finaux souhaitent pouvoir ajouter des champs dans les différents formulaires si ils ressentent le besoin de récolter nouveaux types d’informations. Exemple tout bete: on récolte les informations sur les employés de l’entreprise à travers un formulaire qui comporte un champ téléphone fixe et il s’avert qu’on veuille ajouter un champ téléphone mobile. Jusque là so far so good, cependant afin de sauvegarder cette nouvelle info en base de données, typiquement on va devoir ajouter une nouvelle colonne dans la table Employée de notre base…
L’application étant développée avec zend framework, c’ets donc là que se pose la tuile car on vient de modifier le modèle de données et donc il faut régénérer le modèle via doctrine ou propel ou la main sous zendDB. Il n’est évidemment pas question de livrer au client une appli sur laquelle il va devoir faire des lignes de commande pour générer des classes du modèle de données.
ma question: Comment structurer ma base de données pour que je puisse faire les modifications attendues par mon client sans passer passer par l’ajout d’une nouvelle colonne et donc une modification du modèle de données nécessitant une régénération des classes du model?
Exemple de tables: Produits (prix, description, nom), Magasins(adresse, type)
exemples formulaire: saisie info produits, saisie info magasin
Exemple modification: on veut pouvoir saisir et enregistrer en base le nom du fabriquant du produit, et l’on voudrai pouvoir saisir et enregistrer en base le nom du gérant du magasin. Comment pourrai t on structuré la base de donnée pour qu’elle puisse sous zend framework permettre ce type d’opération: ajout de champ formulaire et possibilité d’enregistrer les nouvelles saisies sans modifier la structure de la BDD?
Salut Julien,
Le lien vers le tuto est mal formé, booh !
http://julien-pauli.developpez.com/tutoriels/zend-framework/atelier/modeles-puissance/" <br />
Très bon article comme toujours. En revanche j’ai du mal à appréhender la répartition de ton code entre ton objet métier, ton model et ton controlleur ? quoi mettre dans chaque ? j’ai du mal à voir la frontière entre objet métier/controlleur, objet métier/model.
As tu plusieurs exemples concret ou carrément une petite application basé sur cette architecture. Merci.