Zend FR

Non ca ne l'est pas
Tu n'a aucun modèle la.

Il te faut un modèle pour chacune de tes bases de données. C'est lui qui fait appel (automatiquement, en héritant de Zend_Db_Table_Abstract) et ce contrôleur fait appel aux méthodes du modèle.

Si ta méthode "delete" comporte de multiples requêtes, tu les place dans le modèle. Pas dans le contrôleur.

Ainsi si tu désire, à un autre endroit de ton application, supprimer un uplet, tu fait appel à ta méthode delete et tu ne répète pas toutes des requêtes.

A voir : http://framework.zend.com/docs/quicksta … base-table

Salut,

Il y a plusieurs réponses à cette question.

Premièrement et simplement, si tu veux répondre correctement à la méthode de conception MVC, non tes requêtes ne sont pas au bon endroit

- Le controlleur invoque le modèle, prépare et transmet les données formatées qui doivent être affichées à la vue
- Le modèle traite la demande du controlleur (métier : SQL ou autre) et renvoie le résultat ou une réponse au controlleur
- La vue affiche les données envoyées par le controlleur.

Il faut donc que tu crées des classes représentant ta couche métier (données, Models = M de MVC) avec lesquelles communiqueront tes controlleurs.

Dans les controlleurs tu identifies le bon model, tu appelles la méthode de ce model qui te renvoie les données voulues, et c'est dans le model et dans la méthode que tu exécutes ton SQL et renvoie un résultat.

Le controlleur ne fait que recevoir le résultat et le préparer pour l'envoyer à la vue.


Après en dehors de MVC, si on réfléchie plus profondément à la conception, on peut ajouter une notion d'interface, que les codeurs ont plus ou moins le réflexe de faire, pas forcément proprement, et sans savoir que c'est un design pattern à part entière. Le terme façade (employé par sekaijin qui a indéniablement plus d'expérience que moi :p) est peut-être plus approprié je ne sais pas.

Une interface qui permet de cacher la partie métier (les données) au controlleur qui n'a pas besoin d'en connaitre l'organisation.

Le controlleur va lui communiquer toujours de la même manière avec l'interface, qui elle va se charger d'invoquer les modèles et servir de relais entre le métier et les controlleurs.

Pour être plus clair, c'est comme si ta partie métier pouvait parler soit français, soit russe, soit anglais, soit araméen, etc., et toi de ton côté tu inventes une langue universelle, tes controlleurs parlent tous cette langue, l'interface est un traducteur.

Première avantage : rendre encore plus simples les échanges, et donc pouvoir vraiment séparer plus efficacement les différentes parties du développement : métier, application, montage, en fournissant une documentation de l'interface.

Deuxième avantage : assurer la pérennité (interopérabilité) de l'application qui se détache totalement de la technologie utilisée pour la partie métier. Tu peux débrancher la partie métier et en rebrancher une autre, seule l'interface change.
De plus, si l'interface existe et que le métier est toujours à l'étude, ça permet de commencer le dev de l'application sans même avoir terminé la conception de la partie métier, l'application fonctionnera donc à vide.

C'est intéressant de se pencher sur cette question.

De mon côté je fonctionne toujours de cette manière, et je ne me soucie donc pas de ma partie métier, je peux y réfléchir tranquillement.

L'interface elle est étudiée de façon logique et regroupe un ensemble de méthodes parlantes.

C'est assez court, cette conception nécessiterait bien plus d'explications, mais c'est pour donnée une première approche, et ce n'est pas forcément ce que tu souhaites faire.


Mais ça pourrait pourquoi pas te donner envie d'approfondir la question :-)


A+ benjamin.

Dernière modification par Delprog (16-02-2009 18:17:18)

merci à tous pour les réponses c'est beaucoup plus clair

Sorry j'ai lu ton message est j'ai écrit une réponse mais au moment de le poster panne de DNS
donc le voilà
pour faire simple et comprendre le fonctionnement de MVC tu fais une classe Modele
comme ça

class Model {

   protected $_db = null;

   public function __construct  () {
      $this->_db = Zend_Db_Table::getDefaultAdapter ();
   }

   public function findByName($name) {
      return $this->_db->fetchAll ( "SELECT plan_id FROM  plan_list WHERE plan_name = '" . $name . "'" );
   }

   public function deletePlanById($id) {
      return $this->_db->query("DELETE FROM plan_availability WHERE plan_id = '".$id."'");
   }

   public function deletePlanListByName($name) {
      return $this->_db->query("DELETE FROM plan_list WHERE plan_name = '".$name."'");
   }

   public function setUserPlanIdById($migrateid, $id) {
      return $this->_db->query("UPDATE users SET plan_id='".$migrateid."' WHERE plan_id ='".$id."'");
   }

}

ce qui te donne un contrôleur ainsi

    public function removeAction() {
        $this->view->message = '';
        $model = new Model ();
        $f = new Zend_Filter_StripTags ( );
        $name = $f->filter ( $this->_getParam ( 'id' ) );
        $migrateid = $f->filter ( $this->_request->getPost('migrate'));

        if ($this->_request->isPost() && isset($_POST['migrate'])) {
            Zend_Loader::loadClass ( 'Zend_Filter_StripTags' );

            if (isset($_POST['oui'])) {
                $id= $model->findByName($name);
                $result2=$model->deletePlanById($id[0]['plan_id']);
                $result=$model->deletePlanListByName($name);
                $result3=$model->setUserPlanIdById($migrateid, $id[0]['plan_id']);

                if ( $result->rowCount($result) <> 1 ||  $result2->rowCount($result2) <> 1 || $result3->rowCount($result3) <> 1) {
                    $this->view->message = 'Erreur dans la suppression';
                }else {
                    $this->_redirect('/plan/list');
                }
            } else {
                $this->_redirect('/plan/list');
            }
        }
        $this->view->title = "Suppresion de plan";
        $this->view->content = "Voulez vous vraiment supprimer le plan : ".$name."";

        $form = $this->confirmationdelete($name);
        $this->view->form = $form;
        $this->render ();
    }

tu as donc simplement séparé la couche M du Contrôleur.
pour aller plus loin tu découpe ton modèle en plusieurs classe en fonction des objet manipulé par exemple et tu auras la voie ouverte à une vrai implémentation de MVC
A+JYT

Zend_Db_Table_Abstract permet de faire un modèle en 3 lignes :

class Table_Model extends Zend_Db_Table_Abstract {
    protected $_name = 'model' ;
}

et ensuite

$table = new Table_Model() ;
$table->insert($data) ;

Le mieux, à mon avis, étant d'étendre Zend_Db_Table_Abstract vers sa propre classe modèle de base et d'y ajouter des fonctions dynamiques de type fetchEntry, fetchAll, save, etc... qui fonctionneront facilement avec n'importe quelle table.

Ces classes ne sont pas des interfaces mais des classes abstraites. Row et Rowset disposent de leur propre classe abstraite que tu peux étendre de la même manière.

class Table_Model_Row extends Zend_Db_Table_Row_Abstract {
    ...
}

class Table_Model_Rowset extends Zend_Db_Table_Rowset_Abstract {
    ...
}

Tu spécifies que tu veux utiliser cette classe dans ton modèle de table en définissant la variable membre $_rowClass ou $_rowsetClass. Ensuite tous les "row" ou "rowset" retournés par ton modèle dériveront de ces classes. Libre à toi d'y ajouter n'importe quelle méthode.

cela te permet surtout de séparer la couche métier de la couche persistance
les classes Zend_Db_*** sont des classe destinées à la persistance en base de données

si tu manipule par exemple un Plan un plan est un objet qui a certaine propriété et sur le quel on peut faire certaine chose. mais un plan n'est pas à priori un enregistrement dans une base de donnée.

ton objet métier est donc un plan
tu défini une classe Plan qui va contenir toutes les propriété et les méthodes définissant cet objet.

ton application va donc pouvoir manipuler des plans tu imagine que des classe d'objet comme celui-là ton application en manipule beaucoup

du coup tous tes contrôleur doivent connaitre ces classes métier pour pouvoir manipuler les objets.
ça peu vide devenir compliqué si tu change un objet métier il te faut faire le tour de tout tes contrôleurs pour répercuter la modif
ce que Delprog appelle un interface s'appelle en réalité une façade.
pour éviter en partit le problème précédent tu crée une classe qui va fournir des fonctions d'un haut niveau d'abstraction aux contrôleur et qui se chargera de connaitre le ou les objet métier à invoquer pour y arriver
comme dans ton exemple une seule fonction redifineUserPlan pourrait suffire à elle de savoir qu'il faut utiliser la classe plan et la classe user

tu noteras que je n'ai pas encore défini si ma classe plan permet de conserver ou pas les objet ni comment
cette partie là s'appelle la persistance. elle à pour but de définir quoi et comment on conserve les objets.
imagine que tes user soit dans un annuaire LDAP et tes plans dans une base. ça ne change rien sur ce qu'est un plan ou un user
ça change tout quant à la façon de conserver les objets. si tu veux garder tes plans en base il te faut donc définir une méthode pour le faire c'est là que les classes Zend_Db_** interviennent tu crée une classe
Model_Plan_Table qui dérive de Zend_Db_Table qui sera ta collection de Plans dans laquelle tu iras chercher tes plan tu peux aussi créer Model_Plan_Table_Row qui dérive de Zend_Db_Table_Row qui représente un enregistrement.  tu vas donc demander à la table de te donner quelque chose elle te donnera un row ces données là tu les place dans ton objet Plan pour le manipuler
dans le sens opposé tu prends les données de l'objet Plan tu en fais un Row que tu enregistre ou tu les donne à l'objet table pour qu'il les enregistres

tout cela n'a rien d'obligatoire mais cette séparation va te permettre de garder un capacité d'évolution que tu n'aurais pas sans. par exemple tes User son gérés en Base puis suite à une évolution de ton SI ils sont gérés dans LDAP (tu ne change que la partie persistance)

cela permet aussi d'améliorer la maintenance si tu à un problème sur un traitement métier c'est dans l'objet métier si tu as un pb pour lire ou enregistrer c'est dans la persistance

cela est un modèle de conception bien défini et la littérature abonde sur le sujet. maintenant il faut aussi être pragmatique si tu ne manipule qu'un seul type d'objet simple sans traitement métier et juste avec de la persistance il n'est peut être pas nécessaire de monter une usine à gaz

chez moi j'ai implémenté la chose de cette façon j'ai donc une façade entre le contrôleur et le modèle
plusieurs classe métier pour chaque classe métier si elle a de la persistance elle implémente un interface à moi appelée collectionnable qui dit simplement qu'on peu enregistrer l'objet
ensuite suivant le type de persistance fichier base LDP xml etc. j'ai une classe collection et une classe row
typiquement pour une base elles dérivent des classes Zend_Db_**
la classe collection se charge de l'acces au donnée et la classe row définit le format des données et le suivit des modifs

ma façade pour les objet persistant va contenir des chose comme getPlanById ou newPlan ou encore assingPlanToUser ces méthodes là vont déterminer quels objets doivent traiter la demande et les invoquer
mes objet métier persistant vont implémenter la méthode save de l'interface collectionnable et le controleur pour donc demander l'enregistrement en base par un simple appel à cette méthode c'est l'objet métier qui déterminera quelle est sa couche de persistance et qui lui demandera de faire le boulot que ce soit un ajout ou une mise à jour.

A+JYT

Salut,

1 : Oui, les modèles ne doivent jamais communique directement avec les vues.
2 : Non. Les formulaires doivent pour moi être déterminés par la vue, leurs traitements par le controlleur. Je ne suis donc pas d'accord avec les choix de Zend de créer le formulaire (du html) depuis le controlleur, même si je comprend pourquoi ils l'ont fait.
3 : non



Les modèles de données et les vues ne doivent jamais communiquer directement.

C'est justement le rôle du controlleur. Le controlleur sait ce qui doit être affiché et dans quelle forme (formatage) dans la vue (donc au client, à l'utilisateur, le résultat), et il sait comment le demander au modèle.

Son rôle est justement de faire le lien avec la couche métier et de comprendre les actions de l'utilisateur.

La vue ne doit faire qu'afficher (mise en page), les données envoyées par le controlleur qui lui les a préparé pour cet affichage.

Le modèle représente les données, leurs organisations et les traitements qui doivent leurs être associés.

Donc pour résumer :

- Le modèle manipule des données (au sens technologique du terme)
- Le controlleur invoque le modèle, prépare le résultat pour l'envoyer à la vue
- La vue affiche

Ici s'arrête la conception MVC.

Ce dont on parle plus haut doit être envisagé une fois que ces notions ont déjà été bien comprises.
La façade permet de réellement séparer la couche métier de la persistance. Ce que ne fait pas complètement le modèle de conception MVC, qui lui sépare des couches mais les laissent quand même dépendantes les unes des autres.


A+ benjamin.

Dernière modification par Delprog (20-02-2009 14:15:16)

Hello,

Mes formulaires sont dans mes modèles. Le contrôleur demande au modèle le formulaire (->getForm()), si la requête est POST, je le vérifie (->isValid()) sinon je l'envoie à la vue.
Si la vérif est valide, je fais le traitement (avec réaffichage de la page ou non), sinon je l'envoie à la vue avec les messages d'erreurs.

A part un 'echo $this->form', je n'ai rien d'autre concernant le formulaire dans la vue.

A+

ALkyD a écrit:

sekaijin :

Par exemple pour mon contrôleur Article, chaque action 'ajouter' et 'editer' utilise un même formulaire, l'un l'affiche vierge et l'autre pré-remplis. Pour rester dans la logique du MVC, une simple méthode privée _getForm() dans le contrôleur fait l'affaire ? Et si j'ai besoin de réutiliser mon formulaire pour un autre contrôleur ?

C'est bien pour cela que je les mets dans les modèles. J'ai dans ton cas un getFormAdd() et getFormEdit(), getEditForm surcharge getFormAdd en y ajoutant des champs si besoin (genre auto_increment de bdd). Pour le remplissage, tu fais un populate($data) sur le formulaire (Add ou Edit)

A+

sekaijin a écrit:

pourquoi le contrôleur ne porte-t-il pas cette méthode ?
si le formulaire est utilisé dans plusieurs contrôleur pourquoi ne pas avoir une classe Application_Controller_Action dont les contrôleur dérive.

Il n'y a aucun intérêt à le mettre dans le modèle.

Imagine que tu doive utiliser dans une autre application ta classe article et que dans celle-ci il n'y a pas de formulaire. mieux l'IHM est faite en FLEX avec des formulaire Flex ou encore avec une vue en SVG

imagine que tu doive créer un service SOAP qui expose des fonctionnalité utilisant ta classe article

pour ce qui est de ton pb de form je ne fais absolument pas comme ça j'ai une action qui affiche un formulaire d'article elle ne fait rien d'autre
si une action comme edit ou add doit afficher le formulaire je fais un forward ou un redirect
si une action d'un autre contrôleur doit afficher le formulaire un redirect suffit

A+JYT

Très franchement, je ne vois pas le problème d'associer le formulaire au modèle plutôt qu'un contrôleur dans tes propos. La présence d'une méthode getForm() dans mon modèle n'influence pas les cas ci-dessus. Ou alors je passe à côté de qqch (sachant que je n'ai dormi que 3h, c'est pas non plus impossible ).

A part ça, je ne fais jamais de forward et le moins possible de redirect.

A+

Bonne question. Pour ma part, je renvoie toujours un tableau PHP (utile pour sérialiser ensuite en JSON dans le controlleur si par ex. on doit afficher des données via Ajax) ou un string, mais jamais une instance Zend_Db_*.

Dernière modification par ALkyD (20-02-2009 17:21:34)

Je comprends à la lecture de ta parabole que pour toi un formulaire s'apparente plus au rendu, mais pas pour moi. C'est pour moi un objet capable de recevoir des données, de les filtrer, de les valider. Ensuite je passe l'objet Form à un objet View qui en effectue le rendu HTML. Pour moi un Zend_Form est donc plutôt lié à la gestion de données (donc au modèle) qu'au rendu.

Ton message me conforte tout de même dans l'idée de faire de l'informatique plutôt que d'aller dans le bâtiment .

A+