Architecture MVC avec ou sans classes métier ?

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.

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 :aie:.

Bref...

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

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.

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.

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.

Citation:

---

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 ;)

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 !

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?

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:

---

1 2 3

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

---

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...

Citation:

---

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 :?

Citation:

---

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 ? ;).

Je ne comprend pas pk on mettrais les classes métier dans le dossier models 8O 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.

Citation:

---

Envoyé par Yoteco

Je ne comprend pas pk on mettrais les classes métier dans le dossier models 8O 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.

Citation:

---

Envoyé par Yoteco

Je ne comprend pas pk on mettrais les classes métier dans le dossier models 8O 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.

Citation:

---

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...

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

Citation:

---

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.

Citation:

---

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?

Citation:

---

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 :

Citation:

---

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 :

Citation:

---

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

---

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

Citation:

---

/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 :

Citation:

---

/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 !

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

Citation:

---

Envoyé par Guardian_7

C'est pas compliqué, sauf à expliquer !

---

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code:

---

1 2 3 4 5 6 7 8 9

application /default /controllers /models /views /engine /controllers /models

---

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

application /default /controllers /models /Default /Db /Table /views /engine /controllers /models /Engine /Db /Table

---

C'est bien juste?

Citation:

---

Envoyé par coolcoco

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code:

---

1 2 3 4 5 6 7 8 9

application /default /controllers /models /views /engine /controllers /models

---

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

application /default /controllers /models /Default /Db /Table /views /engine /controllers /models /Engine /Db /Table

---

C'est bien juste?

---

Oui c'est bien juste :), mais ...

Selon ton exemple tu devras nommer tes classes métier de cette façon :

Default_Db_Table
Engine_Db_Table

Les préfixes sont un peu long non ? Tu pourrais utiliser uniquement les 2, 3 ou 4 premières lettres du module métier pour te simplifier les choses...

Par ex. le répertoire "Default" se nommerait "Def", le répertoire "Engine" "Eng"
Et les classes Def_Db_Table, Eng_Db_Table...

Ca devient particulièrement utile si tu as des longs noms de modules.

Bye

P.S (pour tout le monde) : Conventions de codage PHP du Zend Framework.

Citation:

---

Envoyé par coolcoco

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code:

---

1 2 3 4 5 6 7 8 9

application /default /controllers /models /views /engine /controllers /models

---

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

application /default /controllers /models /Default /Db /Table /views /engine /controllers /models /Engine /Db /Table

---

C'est bien juste?

---

je ne suis pas d'accord
au niveau de ton métier ta classe représente un objet de ton métier
Client, Facture, Automobile, Boulon, Artistes, Album etc.

le contrôleur n'a pas à savoir que ton objet métier dépends d'une base de donnée ou d'un annuaire LDAP ou de tout autre chose
C'est à ton métier de se débrouiller avec sa source de donnée. ainsi si elle change c'est ton objet métier qui change et non pas l'ensemble de ton application.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

application /default /controllers /models Client.php /Client Table.php /views /engine /controllers /models Automobile.php /Automobile /Table.php

---

Le contrôleur dans default accéde à Client.php en fonction de ses besoin ce dernier lui pioche dans model/Client pour utiliser les classes dont il a besoin. par exemple Table.php si la source devient LDAP tu place là une classe Ldap.php qui fait le nécessaire et tu modifie Client.php ainsi ton control leur ne change pas.

Le modèle est le modèle logique de ton application le métier ce n'est pas la représentation que tu à choisis pour l'implémenter.
rien n'interdit à Client.php d'utiliser Facture_Table s'il en a besoin mais ce n''est pas Facture_Table qui doit être utilisé par le contrôleurs pas plus que Client_Table ou Client_Ldap

A+JYT

Citation:

---

Envoyé par sekaijin

je ne suis pas d'accord
au niveau de ton métier ta classe représente un objet de ton métier
Client, Facture, Automobile, Boulon, Artistes, Album etc.

le contrôleur n'a pas à savoir que ton objet métier dépends d'une base de donnée ou d'un annuaire LDAP ou de tout autre chose
C'est à ton métier de se débrouiller avec sa source de donnée. ainsi si elle change c'est ton objet métier qui change et non pas l'ensemble de ton application.

[...]

Le modèle est le modèle logique de ton application le métier ce n'est pas la représentation que tu à choisis pour l'implémenter.
rien n'interdit à Client.php d'utiliser Facture_Table s'il en a besoin mais ce n''est pas Facture_Table qui doit être utilisé par le contrôleurs pas plus que Client_Table ou Client_Ldap

A+JYT

---

Tel quel, tu introduis un problème de conception orientée objet, ça n'a plus grand chose à voir avec les conventions de codage de ZF (c'est la problématique récurrente ici).

On pourrait effectivement introduire une abstraction entre les classes métier et les contrôleurs mais à ce moment là "Engine/Client.php" devrait étendre la classe abstraite, Engine/Abstract.php. De cette manière la convention de codage serait respectée. (Engine_Client extends Engine_Client_Abstract).

Code:

---

1 2 3 4 5 6 7 8 9 10

application /default /controllers /models /Default Client.php Abstract.php /Db /Table

---

Note : Si cette couche d'abstraction n'a pas été définie durant la phase de conception (et que les contrôleurs utilisent directement les classes concrètes) : on peut progressivement refactoriser la structure en définissant une interface, le cas échéant, Engine/Interface.php

Merci de vos réponses...

Je viens du monde Ruby on Rails... et jusqu'à maintenant je mettais toute la logique de l'application directement dans les contrôleurs. C'est marrant de voir que c'était pas forcement à 100% juste.

PS: Guardian_7, aussi neuchâtelois à ce que je vois ;-)

Citation:

---

Envoyé par coolcoco

Merci de vos réponses...

Je viens du monde Ruby on Rails... et jusqu'à maintenant je mettais toute la logique de l'application directement dans les contrôleurs. C'est marrant de voir que c'était pas forcement à 100% juste.

PS: Guardian_7, aussi neuchâtelois à ce que je vois ;-)

---

Le monde est petit ;)

C'est bien de savoir remettre ses méthodes en question, de temps en temps !

Bonjour,
et bien lorsque je vois une discussion comme celle là, je me dis que ceux qui pensent qu'avec PHP on programme mal n'ont qu'a bien se tenir.

Bon je rajoute ma pensée qui vaut ce quelle vaut mais bon.

Pour moi le M de MVC veut clairement dire metier. et pour moi l'arborescence suivante n'est pas la meilleur:

Code:

---

1 2 3 4 5 6 7 8

application /default /controllers /models /views /engine /controllers /models

---

en effet par exemple si j'ai un module panier et un module article, le panier aura surement besoin du model article pour verifier si il reste des articles. Donc pour moi tous les modeles doivent etre dans un seul dossier extérieur au module:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

application /default /controllers /views /engine /controllers /views /models /panier PanierMetier.php /table PanierTable.php

---

comme ça toute les classe métier sont accessible par n'importe qu'elle module et on encapsule l'accès aux différent type de donnée (fichier , mysql ...)

Et enfin , merci à developpez.net pour fournir des discussions comme celle-ci.:D

Citation:

---

Envoyé par bbmt

Donc pour moi tous les modeles doivent etre dans un seul dossier extérieur au module:
...
comme ça toute les classe métier sont accessible par n'importe qu'elle module et on encapsule l'accès aux différent type de donnée (fichier , mysql ...)

---

Ça se discute, l'avantage des modules c'est de découper ton application en sous unités indépendantes mais aussi de les rendre portables.

Si aujourd'hui je développent un module pour gérer des contacts et que d'autres veulent l'utiliser il faudrait que dans le meilleur des mondes il puissent l'installer par un simple copier/coller. Mais ça se complique si j'ai une partie des modèles hors du module.

Mais rien empêche un module d'accéder au modeles d'un autres. Donc demain je peux très bien développer un module newsletter qui aura besoin du module contacts pour fonctionner. newsletter utilisera alors la logique métier de contacts pour récupérer les contacts inscrit à la newsletter.

Cette logique reste aussi valable pour une webagency qui pour chaque projets va réutiliser un ou plusieurs modules déjà développés. Dans ce cas, il ne faut pas que les intégrateurs aient à courir après des bouts de code à gauche et à droite.

Donc tout dépend des objectifs, mais j'aurai tendance a laisser mes modeles dans les modules.

--
Laurent