Discussion :

[Yoshio]

Bonjour,

J'ai lu dans l'article traduit de Rob Allen qu'il fallait mettre les requête SQL dans le dossier /models/.

Donc si je veux gérer des news,
Sur la page d'index de mon site, j'affiche les quelques dernière news.
Sur la partie admin de mon site, 'ajoute, modifie et supprime une news.

Pour faire ces 4 action la (afficher, ajouter, modif et supprimer), je dois créer une classe qui va hériter de Zend_Db_Table qui contiendra des méthodes avec les requêtes sql ?

Est ce que c'est comme ca qu'il faut faire? Ou est ce que je suis complètement à côté de la plaque ?

Un ptit mot sur l'utilité de ce "système" serait le bienvenue ca j'ai jamais fait de site suivant un modèle MVC avant.


Yoshio

[vg33]

En gros, c'est ça.
Le contrôleur est là pour appeler différentes méthodes nécessitées par l'action et pour passer les données à la vue appropriée.
Le modèle accède lui aux données.
Le contrôleur doit être complètement indépendant de la source de données. Comme cela, si tu changes de source de données (tu passes d'un fichier XML à une base de données, par exemple), tu ne touches pas aux contrôleurs, mais tu modifies uniquement le(s) modèle(s).

[Yoshio]

Oki Merci c'est a peu pres ce que je voulais savoir

[sekaijin]

dans le schémas MVC chaque partie à sont rôle à jouer et pour en tirer le plus de bénéfice il convient de respecter ses rôles.
La vue ne sert qu'à faire de la présentation. elle ne dois effectuer aucun traitements.

le controller est un chef d'orchestre qui dit à la vue QUOI afficher et surtout pas comment. il n'effectue aucun traitement. il demande au modèle d'effectuer les traitement approprié. il assure la liaison entre la vue et le modèle.

le modèle effectue tous les traitements de l'application. et rien d'autre il n'est ici aucunement question de l'utilisation de ses traitement ni comment il seront rendu.

bien évidement il n'est pas toujours simple de savoir où placer les choses.
par exemple mon modèle travaille avec des date format yyyy-mm-dd alors que ma vue travaille en dd-mm-yyyy qui dois effectuer la conversion.
si je regarde la théorie c'est à la vue de formater les date pour les afficher. je vais donc mettre la méthode dans ma vue. mais quid de la conversion inverse d'un formulaire vers le modèle ? dans ZF je ne repasse pas par la vue.

je peut être tenter de mettre ses méthodes dans le modèle et donc obtenir un modèle dont l'API gère les date en dd-mm-yyyy alors qu'en interne il travaille en yyyy-mm-dd mais je perd de l'indépendance entre mon modèle et sa présentation. et si on me dit que les vue doivent maintenant gérer le français et l'anglais ! je vais avoir du mal à gérer l'évolution.

reste le controller. lui n'est pas censé faire de traitement mais c'est tout de même là que je vais avoir la plus grande souplesse.

on le voit ce n'est pas toujours simple
(dans le cas des dates je peux mettre les méthode de conversion du modèle vers la vue dans la vue et mettre les méthodes dans l'autre sans dans request par exemple)

le problème se pose aussi avec la vérification de formulaire. c'est le modèle qui peu déterminer si les données sont acceptable. mais il ne connais pas le formulaire. et si je le mais dans request (coté liaison avec l'utilisateur ~ vue) il connais le formulaire mais pas le métier. pour résoudre le problème il faudrait que le request transforme les données du formulaire pour les rendre conforme à ce qu'attend le modèle mais cela fait du travail pour pas grand chose. ou alors il faudrait que le formulaire gère les données au format du modèle et là on perd l'indépendance.


ZF fournis de quoi travailler sous la forme VC View Controller et propose de des librairie d'accès au données permettant de construire un modèle. mais le framework lui même ne défini rien quant à ce modèle.

mais il est très simple de remédier à ça.
le but de séparer les couches est d'ajouter de la flexibilité dans le développement et donc de faciliter l'évolution la maintenance et la réutilisation.

depuis plusieurs années maintenant j'utilise cette approche en php et en plus du design patern MVC j'ai ajouté le design pattern Façade.

une façade est un objet qui ne fait que définir une interface sur un sous ensemble d'éléments plus complexe de façon à cacher cette complexité.

le modèle d'une application est l'exemple type pour une façade.
imaginez que vous faite votre application avec ZF et que vous ayez une classe action.php dont tous vos controller d'action dérivent.
dans cette classe à l'initialisation vous instanciez une classe Model qui est votre façade sur votre modèle.
dans vos actions vous n'avez plus besoins de connaître les classes du modèle
ni de savoir quelle classe fait quoi. vous avez besoin d'un client dont vous détenez l'identifiant
$this->getModel()->getClientById($monId);
vous avez besoin de modifier le nom d'un utilisateur
$this->getModel()->setUserNameByLogin('Sekaijin', 'Terrien');

et c'est tout pour le contrôler.

pour le modèle vous gardez les classes comme vous avez l'habitude de le faire. et dans la classe Model vous ajoutez les méthode dont vous avez besoin.
ces méthode ne font qu'une chose identifier le meilleur candidat (classe du modèle) pour effecteur le travail
et l'invoquer.

ça ne sert à rien me direz vous. ben non ça ne sert pratiquement à rien. sauf que votre modèle est maintenant indépendant de son utilisation. vos classes métier ne sont instanciées qu'à un seul endroit. et vous allez encore gagner en souplesse.
par exemple vous travaillez en équipe. un designer fait de beau écrans (vue). un développeur assure la cinématique de l'application (controller). et un concepteur fait la partie métier (model)
il suffit de se mettre d'accord sur la classe Model pour que ces deux personnes puissent travailler indépendamment. le concepteur se concentre la sur la définition des objets métier. je développer de controller lui invoque des méthodes du modèle qui dans un premier temps peuvent être de simple bouchons. au final le tout peut être assemblé sans trop de difficultés.

mais il y a encore mieux. mon application est écrite en utilisant cette façade. mes utilisateur sont dans ma base de donnée
si je regarde mon modèle ci dessus j'ai la méthode setUserNameByLogin
celle-ci va chercher la classe user et invoquer la méthode approprier qui elle-même ira enregistrer tout ça dans la base.
on me demande de faire évoluer le modèle car mes utilisateur ne sont plus enregistré dans la base mais dans l'annuaire de l'entreprise.
je change complètement la classe user pour changer sa méthode d'accès au données. mais je dois aussi changer la connexion. vu que j'ai une façae je n'ai qu'un seul endroit ou est instancié ma connexion mais je n'ai aussi qu'un seul endroit ou est instancié ma classe user. si je ne change pas l'interface de ma méthode je peux changer toute l'organisation de mon modèle sans avoir à toucher aux controllers.

ma classe Model va donc capitaliser tous les accès au modèle.
un exemple est parfois plus parlant voici une copie partielle d'une telle façade.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php
// Classe generique d'acces au modele.
Zend_Loader::loadClass("Fast_Model");
 
class Model extends Fast_Model {
 
   /**
   * Gestion des Users
   */
   function hasCollectionUser(){
      return $this->getCollectionByName("um_user");
   }
   // retourne la collection User (gestion des Users de l'application.)
   function getUserCollection(){
      return $this->getCollection("um_user",'Um_CollectionUser');
   }
   // retourne les Users correspondants ou False.
   function getUserByExemple($nom, $prenom, $login, $email, $equipe, $workgroup){
      $collection = $this->getUserCollection();
      return $collection->getUserByExemple($nom, $prenom, $login, $email, $equipe, $workgroup);
   }
   // retourne les Users correspondants ou False.
   function findUsers($pattern){
      $collection = $this->getUserCollection();
      return $collection->findUsers($pattern);
   }
   // retourne le User correspondant ou False.
   function getUserByPseudo($pseudo, $pass="NULL"){
      $collection = $this->getUserCollection();
      return $collection->getUserByPseudo($pseudo, $pass);
   }
   function getUserById($id){
      $collection = $this->getUserCollection();
      return $collection->getUserById($id);
   }
   function userExists($ident){
      $collection = $this->getUserCollection();
      return $collection->userExists($ident);
   }
   function newUser($obj=null,$tr=null) {
      $collection = $this->getUserCollection();
      return $collection->newUser($obj,$tr);
   }

comme on peu le voir la façade ne fait que définir une API sur le modèle qui pourra être utilisé partout dans l'application, t qui rend le modèle bien identifié et clairement défini

A+JYT