Zend FR

booradley · 18-01-2009 17:23:58

Bonjour,
J'essaie actuellement de rendre mon code plus propre avec MVC.
Dans chacun des controlleurs de mon module user, j'ai :

- une partie d'accès au modèle (requête SQL sur la table "user") :

Code:

$listeUsers = UserSql::getListeUsers($args);

- une partie traitement lié à un objet ("UserObject")

Code:

for($i=0;$i<sizeof($listeUsers); $i++) {
$item = $listeUsers[$i];
 $user = new UserObject($item);
$identifiant = $user->getIdentifiant();
....
...
}

- une partie traitement divers

Comme je réutilise cette portion de code a 2 endroits, j'ai créé un helper qui mutualise le code ci dessus et que j'appelle via 2 controlleurs différents :
/user/get-liste-users/
/user/ajax-get-liste-users/

Ma question est simple, y a t'il une nomenclature particulière à respecter ou usitée pour les noms de mes classes UserSql (requetes sql) et UserObject(traitements sur mon objet).

Delprog · 18-01-2009 17:47:45

Bonsoir,

MVC n'impose pas de nomenclature particulière pour le nom des classes.

Zend recommande de nommer les classes models comme les tables. Ils recommandent aussi de respecter une convention du type Xxxx_Xxxx_XxxxXxxx pour les noms des classes, l'underscore (_) devant représenter un noeud dans l'arborescence de dossiers.

Donc si tu nommes une classe Truc_Bidule_Chouette et qu'ensuite tu l'include par un Zend_Loader::loadClass('Truc_Bidule_Chouette'), il s'attend à trouver une classe Truc_Bidule_Chouette dans le fichier Chouette.php dans le sous-dossier Bidule du dossier Truc. Je pense (mais je n'en suis pas sûr) que le séparateur doit être paramétrable dans Zend. Par défaut c'est underscore (_).

Après chacun fait ce qui lui plait le mieux. J'aime bien les conventions mises en place par Zend, mais attention elles ne viennent pas de MVC, qui mis à part la séparation des couches n'imposent aucune convention de nommage.

De mon côté j'ai tendance à regrouper mes classes métier par package/plateforme (abus de langage attention, c'est en réalité un groupe de classes répondant à une partie commune du métier) en les nommant MonPackage_Xxxxx et en les rangeant donc dans le dossier MonPackage. Ainsi je conserve l'utilité de Zend_Loader qui se charge de parcourir les dossiers pour charger la classe, et ça permet à d'autres intervenant de comprendre le rôle de chaque model qui sont regroupés dans un ensemble.

Je ne sais pas si c'est très clair

A+ benjamin.

booradley · 18-01-2009 18:21:27

Oui je comprends bien ce fonctionnement.
Donc si j'ai un projet "MyProject" et un module de ce projet "MonModule" et des traitements métiers spécifiques à ce module je dois les mettre dans /library/myproject/monmodule/MaClasseTraitement.php c'est bien cela ?
J'avoue que ca me choque un peu de mettre ces traitements là bas car cela suppose que ce soit des composants réutilisables non ?
La plupart du temps, c'est du code qui ne l'est pas puisque j'ai tendance à mettre le code réutilisable de mon module dans les action helpers.

N'y a t-il pas un autre endroit plus approprié?

Delprog · 18-01-2009 19:12:58

Non c'est pas ça.

Il ne faut pas confondre librairies et modèles de données, je parlais de conventions d'un point de vue général.

Si on respecte les recommandations de Zend, tu aurais une arbo du type:

Code:

application/
      Controllers/
      Models/
      Views/
      Modules/
            MonModule/
                  Controllers/
                  Models/
                  Views/
            MonModule2/
            etc.
boostrap.php
library/
public/
      images/
      scripts/
      styles/
      index.php

Les classes métier communes à l'ensemble du projet se trouveraient donc dans le dossier application/models, les classes métier proprent à chaque module dans le dossier MonModuleXX/Models.

Maintenant chacun arrange ça au mieux pour ses propres raisons. Personnellement j'ai décidé de sortir le dossier Modules du dossier application, considérant qu'un module peut être indépendant.

Il faut garder à l'esprit qu'il y aura forcément un jour un truc bloquant.

Maintenant en ce qui concerne les helpers ou toute dérivation de classes Zend. Il est conseillé de créer un dossier perso dans library ex. bidon "MyLib" et de rassembler toutes les classes dans ce dossier, par ex. de mon côté j'ai :

Code:

application/
      Controllers/
      Models/
      Views/
Modules/
      MonModule/
            Controllers/
            Models/
            Views/
      MonModule2/
boostrap.php
library/
      Tight/
            Controller/
                  Action.php
                  ...
            Exception/
            Filter/
                  Date.php
                  StringUtil.php
                  ...
            Helper/
            ModelFront/
            Plugin/
            Validate/
                  EmailAddress.php
            Config.php
            Exception.php
            ModelFront.php
            Registry.php
            View.php
            etc. etc.
public/
      images/
      scripts/
      styles/
      index.php

Bon, en réalité j'ai sorti la librairie Tight et j'en ai fait une librairie commune à tous les projets, comme le Zend_Framework, mais c'est la structure ci-dessus (mis à part les modules qui sont habituellement dans application) qui est le plus souvent utilisée.

Donc en gros, tes classes de traitement métier dans les dossier models et tes packages de classes dérivées ou non hein, comme ton helper par ex. dans le dossier library en respectant les conventions de Zend (si elles te conviennent).

Par ex. si tu as ton helper Truc.php dans le dossier library/MyLib/Helper/, que tu ajoutes le dossier library à ton include_path, tu n'as plus qu'à faire à l'endroit voulu un :

Code:

Zend_Loader::loadClass('MyLib_Helper_Truc');

Tes classes métier dans les dossiers models, que tu ajoutes aussi à l'include_path de ton projet et ensuite :

Code:

Zend_Loader::loadClass('Model.php');

Je détaille volontairement parce qu'on voit de tout et n'importe quoi et tu as raison de te poser la question :p

A+ benjamin.

booradley · 19-01-2009 00:25:21

Merci beaucoup pour ton aide Delprog , elle m'a été vraiment utile pour comprendre.
A+
David

sekaijin · 19-01-2009 13:33:06

le contrôleur fait appel au métier
donc dans le métier

Code:

class User {...

qui définit un utilisateur

Code:

class User_Collection {...

qui définit une collection d'utilisateurs

la couche persistance

Code:

class User_Table_Row extends Zend_Db_Table_Row {...

Code:

class User_Table extends Zend_Db_Tabl {...

le contrôleur manipule des User et User_Collection
User_Collection utilise User_Table et User_Table_Row pour accéder à la base et mapper les User sur la table dans la base.

A+JYT

Zend FR

#1 18-01-2009 17:23:58

Séparation données et traitements

Code:

Code:

#2 18-01-2009 17:47:45

Re: Séparation données et traitements

#3 18-01-2009 18:21:27

Re: Séparation données et traitements

#4 18-01-2009 19:12:58

Re: Séparation données et traitements

Code:

Code:

Code:

Code:

#5 19-01-2009 00:25:21

Re: Séparation données et traitements

#6 19-01-2009 13:33:06

Re: Séparation données et traitements

Code:

Code:

Code:

Code:

Pied de page des forums