03-02-2010, 05:33 PM
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 ...
). 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 ...