Architecture MVC avec ou sans classes métier ?

[Yoteco]

Bonjour,

Je me pose une question depuis un bon moment et je n'ai pas vraiment trouvé de réponse à ma question. Je vous l'expose:

Selon le modèle MVC les contrôleurs devraient juste s'occuper de la "connexion" entre les modèles et les vues. Et c'est les classes de la couche métier qui doivent "travailler", dans l'action d'un contrôleur il ne devrait y avoir que quelques lignes de code. (Arrêter moi là si ce n'est pas juste.)

Cependant dans tous les tutoriels que j'ai lu sur le Zend Framework il n'y a pas vraiment de classes "métier" tout est toujours directement codé dans les actions des contrôleurs. Alors est-ce correct de tous coder directement dans les contrôleurs lorsqu'on on utilise le framework de Zend ou est-ce qu'il faut faire des classes métier?

S'il faut faire des classes métier j'ai un peu de la peine à me m'imaginer ce que sa donnerait. Car dans les contrôleurs on utilise beaucoup le $this pour accéder aux valeurs passées en post ou en get, pour passer des valeurs à la vue, pour rediriger, etc... Si on fait des classes métier ce serais stupide de passer ce $this car sa reviendrais à créer une sous-couche inutile.

Voilà j'espère que quelqu'un pourra m'éclaircir.

Merci d'avance.

[Guardian_7]

Hello,

En effet, selon le pattern MVC, le contrôleur ne doit faire que des "liaisons" entre les modèles et les vues.

Il est vrai qu'on retrouve souvent dans les exemples ici et là, du code métier dans les contrôleurs. Il y a trois raisons à cela :

• La flémardise notoire du programmeur,
• le manque d'experience du programmeur,
• le Net est connu pour fournir une quantité remarquable de mauvais exemples !

Utiliser des raccourçis, ça ne remet pas formélement en question le fonctionnement d'une application, simplement sa maintenance, sa marge d'évolution... Sa qualité.

Le choix de la facilité a toujours son effet boomerang. Toujours .

Bref...

Le code métier - à proprement dit - n'a rien à faire dans un contrôleur d'action. Simple question de rigueur !

[Yoteco]

Ok, il me semblait bien.

Mais alors où est-ce que je stocke les classes métier? Je fais un dossier dans library genre My et je crée les classe My_Nom-du-controller ?? Y a une structure à respecter?

Utiliser des classes métier va considérablement faciliter l'implémentation des tests.

[Baptiste Wicht]

Pourquoi un dossier dans library ?

Je mettrais plutôt un dossier logic ou bll dans application, non ? Ensuite, au niveau du nommage des classes, je ne les lierais pas au nom du contrôleur... Une classe métier a un nom propre et peut être utilisée par différents contrôleurs.

[Yoteco]

Oui, j'ai pas bien réfléchis... je vais faire un dossier logic par module. Par contre pour le nom des classes je ne sais pas encore... Le nom des contôleurs sépare bien les différentes parties du module je trouve.

[Baptiste Wicht]

Envoyé par Yoteco

Oui, j'ai pas bien réfléchis... je vais faire un dossier logic par module. Par contre pour le nom des classes je ne sais pas encore... Le nom des contôleurs sépare bien les différentes parties du module je trouve.

Si c'est bien séparé avec les contrôleurs, c'est vrai que tu peux réemployer le nom du contrôleur

Par exemple, si toute la partie de gestion des membres est dans le contrôleur MembresController, tu peux tout à fait nommer ta classe métier Membres

[Guardian_7]

Pourquoi ne pas simplement utiliser la convention de noms du framework ?

Ex. : MembresController.

My_Db_Table_Membres (pour la classe métier "Membres" qui étend Zend_Db_Table...)

My_Db_Table_Row_Membre (... Pour Zend_Db_Row...)

My_Controller_Plugin_Auth (pour un plugin "Auth" qui étend Zend_Controller_Plugin_Abstract)

etc.

Le tout selon l'arborescence décrite dans la doc.

Si ton application est modulaire, à ce moment là tu devras ajouter un préxif aux contrôleurs (à l'exception du module 'default').

Cette convention est simple et plutôt efficace... On l'a retrouve d'ailleurs dans PHPUnit, PEAR & co.

Faut pas aller chercher plus loin !

[coolcoco]

J'ai le même avis que Guardian_7.

Personnellement, j'ai utilisé le dossier "library".

J'ai donc un dossier nommé "lenomdemonprogramme" dans mon dossier library où je met d'autre dossier pour y ranger mes classes.

De plus, grâce à la fonction "spl_autoload_register" de php, tu n'as pas besoin de charger tes classes si tu nommes bien tes fichiers: tu n'auras qu'à faire un
$uneInstance = new LeNomDeMonProgramme_DossierClass_Class;
... et tu auras ton instance, sans import à faire! N'est-ce pas joli?

Par contre, je comprend pas Baptiste Wicht... Pourquoi ne pas utiliser, comme Zend le fait, le dossier "library"... Il est fait pour non?

[Guardian_7]

Petite précision pour le register autoload, il n'est pas nécessaire de passer par la fonction spl : il y a la méthode statique : Zend_Loader::registerAutoload()

Code php :

1
2
3
 
require_once 'Zend/Loader.php';
Zend_Loader::registerAutoload();

[Yoteco]

Pour des sites en production ce n'est pas conseillé d'utiliser spl_register_autoload... Car trop lent.

Pour le placement je trouve pas très juste de le mettre dans le dossier library, car ce n'est pas vraiment une libraire comme l'est le framework...

[Baptiste Wicht]

Envoyé par coolcoco

Par contre, je comprend pas Baptiste Wicht... Pourquoi ne pas utiliser, comme Zend le fait, le dossier "library"... Il est fait pour non?

Euh, pour moi, il est plutôt fait pour les librairies externes que tu rajoutes à ton application. Par exemple, moi j'ai Zend, Smarty et FPDF dans ce dossier, mais je ne vois pas pourquoi on y mettrait nos classes métiers

[Guardian_7]

Envoyé par Yoteco

Pour des sites en production ce n'est pas conseillé d'utiliser spl_register_autoload... Car trop lent.

Que d'idées reçues .

Ce n'est pas spl_register_autoload() qui est trop lente. Cette fonction a simplement pour but de définir un auto-chargeur de classes personnalisé.

Techniquement, c'est la recherche dans le système de fichiers qui peu s'avérer "lente".

En même temps, les require_once ou include_once contrôlent si le fichier existe et si il a déjà été défini dans le flux d'exécution courant, donc en définitif, c'est tout aussi lent...

...Pour améliorer sensiblement la rapidité à ce niveau là, il faudrait utiliser des techniques d'inclusion peu pratiques pour le programmeur ou utiliser des fonctionnalité de cache ou de byte-code.

Et d'une manière ou d'une autre, la puissance des serveurs actuels et les technologies telles que les disques durs flash rendent le problème insignifiant.

...

Les classes "métier" vont dans le rép. models de l'aborsescence conseillée.

Le dossier "Zend" qui figure dans le dossier "library" du fichier de distribution, devrait aller dans un dossier commun, comme le fait Baptiste.

Simple non ? .

[Yoteco]

Je ne comprend pas pk on mettrais les classes métier dans le dossier models Tu tiens ça d'où ? Car dans le dossier models on met les classes qui accèdent à la base de données... Je ne vois pas le lien.

[Baptiste Wicht]

Envoyé par Yoteco

Je ne comprend pas pk on mettrais les classes métier dans le dossier models Tu tiens ça d'où ? Car dans le dossier models on met les classes qui accèdent à la base de données... Je ne vois pas le lien.

Dans l'architecture MVC, c'est le modèle qui effectue tout ce qui est métier. C'est donc logique de mettre tout ce qui est métier dans models, même si le nom peut prêter à confusion.

[Guardian_7]

Envoyé par Yoteco

Je ne comprend pas pk on mettrais les classes métier dans le dossier models Tu tiens ça d'où ? Car dans le dossier models on met les classes qui accèdent à la base de données... Je ne vois pas le lien.

Tu considères le problème à l'envers.

Le MVC n'est pas une invention du Zend Framework, pas plus que de PHP ou du développement Web.

...C'est l'architecture logicielle, le langage, ... le code source (et le programmeur) qui s'adaptent au patron de conception, pas l'inverse.

Envoyé par Dico DVP (MVC)

[...]
Modèle – Encapsule le cœur fonctionnel de l'application, le domaine logique.
[...]

Je pense que tu devrais te documenter plus sérieusement sur le sujet...

[Yoteco]

LOL en effet sorry tout est clair now ;-) Merci.

[Yoteco]

Envoyé par Guardian_7

Que d'idées reçues .

Ce n'est pas spl_register_autoload() qui est trop lente. Cette fonction a simplement pour but de définir un auto-chargeur de classes personnalisé.

Techniquement, c'est la recherche dans le système de fichiers qui peu s'avérer "lente".

En même temps, les require_once ou include_once contrôlent si le fichier existe et si il a déjà été défini dans le flux d'exécution courant, donc en définitif, c'est tout aussi lent...

...Pour améliorer sensiblement la rapidité à ce niveau là, il faudrait utiliser des techniques d'inclusion peu pratiques pour le programmeur ou utiliser des fonctionnalité de cache ou de byte-code.

Et d'une manière ou d'une autre, la puissance des serveurs actuels et les technologies telles que les disques durs flash rendent le problème insignifiant.

...

Alors je viens de profiler un script, une fois en utilisant register_autoload et je ne charge donc aucune page. Puis ensuite sans register autoload et je charge tout les classes à la main avec Zend_Loader::loadClass(); Le résultat est frappant! Sa va beaucoup plus vite si on utilise pas register_autoload. Les chiffres parlent d'eux mêmes:

Avec register_autoload: 586.12 ms soit 40.3% du temps d'exécution total
Sans register_autoload: 145.65 ms soit 15.6% du temps d'exécution total

Donc presque 4 fois plus rapide !!! C'est quand même hallucinat de penser que sur l'exécution d'un script 40.3% du temps est utilisé pour charger des pages... Même 15.6% c'est beaucoup.

[coolcoco]

Envoyé par Guardian_7

Tu considères le problème à l'envers.

Le MVC n'est pas une invention du Zend Framework, pas plus que de PHP ou du développement Web.

...C'est l'architecture logicielle, le langage, ... le code source (et le programmeur) qui s'adaptent au patron de conception, pas l'inverse.




Je pense que tu devrais te documenter plus sérieusement sur le sujet...

Donc si je suis cela, j'aurai, par exemple, un dossier ORM pour qui contiendra, dans le dossier models, les classe étandant Zend_Db_Table, c'est juste?

Mais, si une classe "métier" est utilisé par un autre module de l'application Web... Comment fait-on?

[Guardian_7]

Envoyé par coolcoco

Donc si je suis cela, j'aurai, par exemple, un dossier ORM pour qui contiendra, dans le dossier models, les classe étandant Zend_Db_Table, c'est juste?

Mais, si une classe "métier" est utilisé par un autre module de l'application Web... Comment fait-on?

Regarde de quelle manière sont catégorisées les classes du framework. On peut pas faire plus simple.

Aperçu :

Zend/Db/Table/Abstract.php [Zend_Db_Table_Abstract]
Zend/Db/Table.php [Zend_Db_Table extends Zend_Db_Abstract]
Zend/Exception.php [Zend_Exception]
Zend/Db/Table/Exception.php [Zend_Db_Table_Exception extends Zend_Exception]

Le nom des classes fournit directement l'aborescence du fichier et (implicitement) l'héritage.

Pour les classes métier ça se passe dans le rép. "models" de ton module, ici on admet qu'il s'agit du module métier qui s'appelle "My", exemple pour une classe métier "TableTest" étandant Zend_Db_Table :

/models/My/Db/Table/TableTest.php [My_Db_Table_TableTest extends Zend_Db_Table]

Autre exemple... pour un adapteur auth dénommé "Perso" ...

/models/My/Auth/Adapter/Perso.php [My_Auth_Adapter_Perso extends Zend_Auth_Adapter]

Si ta classe métier n'étant pas un module ZF, tu conserves néanmoins la convention :

/models/My/Autre/Chose.php [classe concrète Autre_Chose]
/models/My/Autre/Chose/Exception.php [classe d'exception Autre_Chose_Exception]

/models/My/Autre/Chose/Abstract.php [classe abstraite Autre_Chose]
/models/My/Autre/Chose/Interface.php [interface Autre_Chose]

Et ainsi de suite...

C'est pas compliqué, sauf à expliquer !

[sekaijin]

Zend_Framework n'implémente pas MVC mais VC c'est à toi de faire le nécessaire pour ajouter le M

ZF te fournit une lib conséquent pour y parvenir c'est tout.

pour la part j'ai une classe Action qui dérive de Zend_Controller_Action
mes contrôleur dérive de cette classe.

elle ajoute une instance d'une classe nommé Model comme membre.
ainsi dans mes contrôleurs je ne me préoccupe pas de savoir où ni comment sont géré les données.

Cette classe Model n'est qu'une façade. elle ne fait rien elle-même mais elle se charge de déterminer quels objet métier utiliser et les appelle.

par exemple mon contrôleur fait

Code :

$myCollection = $this->model->getBookList('SciFi');

la façade elle ne traite pas cette demande elle va choisir l'objet le plus approprié

Code :

1
2
3
4
5
6
class Model {
   public function getBookList($style = null) {
      return $this->getBookLibrary()->getBookList($style);
   }
   ...
}

la classe métier BookLibrary elle va implémenter la méthode getBookList

cela peut paraître compliquer la chose mais en fait ça la simplifie.
imaginez que vous commencez vos dev et que vous n'avez pas la source de donnée vous faite une classe bouchon et vous pouvez développer les contrôleurs et l'ihm
ensuite il suffit de changer le bouchon pour que cela fonctionne.
mieux vous passez de MySQL à LDAP il suffit de changer la classe BookLibrary et la méthode getBookLibrary() de la façade

le principe d'une façade est de masquer la complexité à ses utilisateurs elle définit une API et à elle de faire le nécessaire. du coup toutes les utilisations s'en trouvent simplifiées.

vous pouvez ainsi mixer dans votre partie métier des technologie très différentes DB, LDAP, Telnet, WebServices, XML, Files etc. toute ressource peut être remplacé par une autre par adaptation de la façade
tant que l'api ne change pas rien ne change côté Contrôleur.

Pour plus de détail sur les façade
http://en.wikipedia.org/wiki/Facade_pattern

A+JYT