Comment faire son code proprement en MVC2 ?

[Plume]

C'est amusant, j'avais la même définition de MVC2 que vainsang. Tu vas me mettre le doute Argorate !

J'vais vérifier ça !

[Sephi-Chan]

Je suis du même avis que Vainsang et Plume : avec MVC2, on a un contrôleur frontal qui dispatch vers les autres contrôleurs.


Sephi-Chan

[Argorate]

J'ai fini mes cours la semaine derniere sur design patern et MVC, on a meme eu des intervenants exterieur, et ils ont tous dis la meme chose...
"MVC1 : plusieurs controleurs, MVC2: un seul et unique controleur"...

EDIT:
J'ai d'aillieur eu un intervenant sur STRUTS, et en cherchant sur le net j'ai trouvé ça : http://www.exe6.net/docs/MVC2_Struts.pdf (voir début page 4)
ou encore: http://www.nalis.fr/notre-valeur-ajoutee...leur2.html
et meme Sun : http://jmdoudoux.developpez.com/cours/de...eworks.php

[Sephi-Chan]

Hm, c'est surprenant.

J'ai dû mal à cerner ce qu'utilisent les frameworks tels que Symfony ou Rails…

Une application Web diffère un peu d'une application système, mais tout de même, on retrouve l'idée d'un contrôleur frontal puisqu'il y a un système de routing : c'est le framework qui gère toute la partie qui suit le nom de domaine. Ça implique donc d'avoir un unique point d'entrée qui dispatch vers les autres contrôleurs.

Même si c'est pas vraiment important, ça me travaille, cette histoire. :p


Sephi-Chan

[Anthor]

Le modèle MVC II conserve les principes du modèle MVC, mais il divise le contrôleur en deux parties en imposant un point d'entrée unique à toute l'application (première partie du contrôleur) qui déterminera à chaque requête reçue les traitements applicatifs à invoquer dynamiquement (seconde partie du contrôleur).

D'après tes liens Argo ^^ Qu'il y ait un unique controller, ça ne veut pas dire que derrière tout est figé.

Dans une application web, tous les framework propose un frontController qui dispatche la requête sur les controller.
Tous les framework PHP sont MVC2. Et la plupart des frameworks Web.

D'ailleurs, le MVC2 peut avoir 4 couches, voir plus...
Zend en propose 5 de base par exemple, front Controller, Modules, Controller, Modèle, Vues.

Ça reste du MVC, y'a vraiment qu'ici pour débattre sur du vocabulaire. Le MVC date de 70, il a forcement évolué au cours du temps et des besoins.

[Plume]

Ça reste du MVC, y'a vraiment qu'ici pour débattre sur du vocabulaire.

Soit indulgent Thothor, voyons ! Faut bien que chacun sache de quoi il parle

[Argorate]

Anthor, dans la citation il est dit que c'est découpé en deux parties, pas qu'il y a deux controllers... :p
M'enfin, je me fis a se qu'on m'a enseigné ^^

Mais je me souviens aussi avoir entendu mon prof avoir parlé d'une confusion que les gens faisait entre MVC2 et MVC v2 et il me semble que l'un été utilisé pour dire MVC web (qui comme tu le dit sephi est légèrement différent des appli) et c'était justement un abus de langage des programmeurs web de dire MVC2 au lieu de MVC v2.

Enfin me souviens d'un discourt d'un truc dans ce style, si je recroise le prof en question j'y demanderais, mais je promets rien.
Bref... ^^

[nestoyeur]

Salut à tous, je viens également mettre mon grain de sel dans la discussion, car je suis tombé ici en cherchant justement plus de détail au sujet de ce fameux MVC2 (merci Google ). Je dois d'ailleurs dire qu'il est plutôt difficile de trouver des tutoriels, articles ou autres ressources traitant le sujet en profondeur et c'est pourquoi je viens ici exposer mon avis sur le sujet. Ce n'est donc pas pour étaler ma confiture, mais pour voir les avis qu'il en ressort et tenter surtout d'y voir plus clair. Je précise également que je suis du même avis que vainsang et que c'est cette idée que je vais développer.

Tout d'abord il est clair qu'il y à une confusion et que deux avis ressortent. Dans les deux cas tout le monde s'accorde à parler d'un Controller unique qui est chargé de traiter la requette de l'utilisateur. La ou les avis différent c'est en ce qui concerne non pas le routage mais la manipulation du couple Model-View. En effet, certains disent que c'est ce même Controller unique qui se charge de ça alors que d'autre disent qu'il se contente d'instancier des sous-controller qui s'occuperont de cette besogne.

Je ne saurais pas capable d'affirmer ce qu'il en est réellement dans la définition exacte du design pattern "MVC2" (existerait-il une sorte de norme ?), mais je peux utiliser le bon sens et la logique pour en tirer mes propres conclusions que voici :

J'ai la conviction que l'intérêt du MVC est intimement lié à celui d'un Framework: rapidité de développement, facilité de maintenance, re-utilisabilité du code et travail en équipes. C'est entre autres pour ces différentes raison que l'on sépare le Model, la View et le Controller. Gardons bien en tête que ce qu'apporte principalement le MVC et qui à fais son succès est la séparation du code ("Diviser pour mieux régner") ! En ayant pris conscience de cette évidence, pourquoi vouloir incomber à un même élément à la fois la tache du routage et celle de contrôler le Model et la View ? D'autant plus que la première (le routage) est la même pour tout les projet, tandis que l'autre (manipulation des Model-View) change, pas toujours certes, d'un projet à l'autre.

A partir de la j'ai moi même un souci pour déterminer parmis deux option laquelle serais la plus logique. Prenons une "mise en situation" très basique ( Inspirer du schéma de Zend Framework: http://nethands.de/download/zenddispatch_en.pdf ) :

- L'utilisateur émet une requette à l'application
- Cette requette arrive dans le point d'entrée (exemple: index.php)
- Le point d'entrée transmet la requette au Controller unique (instancie)
- Le Controller unique décortique la requette (routage)
- Il instancie un sous-controller (* Voir plus bas !)
- Le sous-controller manipule le couple Model-View
- L'utilisateur obtiens son résultat (issu du Model et/ou de la View).

Vous noterez la petit étoile et c'est justement ici ou je me pause la question: Pourquoi ne pas utiliser un seul et unique sous-controller pour toute les requette ? Ce qui donnerais tout son sens à ce que du disais vainsang: MVCC !

Par exemple, quand avant on envoyé comme URL: http://monsite.com/membre/inscription pour accéder au controller Membre et à la method Inscription. On aurais à la place toujours le même controller et membre correspondrais à la method tandis que inscription serais un switch dans cette method. L'intêret serais uniquement de réduire le nombre de fichier, car personnellement je ne trouve pas de raison valable à avoir 10 Controller par projet en sachant qu'il y à en moyenne 4 lignes par method ...

[Anthor]

Par exemple, quand avant on envoyé comme URL: http://monsite.com/membre/inscription pour accéder au controller Membre et à la method Inscription. On aurais à la place toujours le même controller et membre correspondrais à la method tandis que inscription serais un switch dans cette method. L'intêret serais uniquement de réduire le nombre de fichier, car personnellement je ne trouve pas de raison valable à avoir 10 Controller par projet en sachant qu'il y à en moyenne 4 lignes par method ...

C'est simple, sur le web tu as besoin de plus de couches ^^
Sur Tarschool par exemple, j'ai une soixantaine de controller, tous composés de plusieurs actions et répartis dans 4 modules.
Avec un MCV tout simple je n'aurais pas eu autant de modularité.

Je rentrerais pas de nouveau dans le débat. Que ceux qui ne comprennent pas que c'est la même chose avec des couches en plus commencent à s'en servir ^^ On fera un débat ensuite sur du concret !

[wildd]

mes .05$

je serais plutot sur la même foulée que anthor.

le MVC "généraliste" à la base ne stipule pas de de chaine de responsabilité rigide, ordre d'intervention, etc... il décompose seulement l'applicatif en 3 sous-groupes majeurs: modèle - vue - controleur

par dessus sont venu les surcouches architecturale MVC2, HMVC, etc... qui précises les règles de conception et tentent de mettre en place une structure "plus cohérente".

après chacun y va de son grain de sel niveau interprétation