Discussion :

[ChriGoLioNaDor]

Bonjour,

J'utilise php5 depuis quelques mois, et cela fait un moment que je me documente sur le modèle MVC. Mon soucis est que, bien que je pense que ce modèle permette de pouvoir avoir des modules fixes (mes classes modèles) réutilisables, et des modules customisable (les classes vues), j'ai l'impression que le MVC reste pour les sites un doux rêve. Je m'explique :

Je prendrais l'exemple d'un livre d'or.

- 1e défaut trouvé : même en séparant le modèle de la vue, un client peut vouloir ajouter des fonctionnalités à son livre d'or.
Ex : l'un veut afficher l'heure, le 2e veut gérer les émoticons, le 3e un système antispam, etc.
Dans ce cas, on peut créer un module "super complet" qui gère toutes les fonctionnalités, mais dans ces cas là on aura à terme une usine à gaz capable de tout faire, mais lentement (36 conditions pour voir quelle fonctionnalité est activée), et pas forcément de façon fiable, s'il y a trop de cas à prévoir.
Sinon, on est obligé de "customiser" ses classes modèles, et là on perd une grande partie de l'intérêt du mvc : avoir des modules réutilisables quel que soit le cas.

- 2e défaut trouvé : Utiliser un modèle MVC implique de diviser chaque module en 2 classes : l'une pour le modèle (commune), et l'autre pour la vue (différente pour chaque site). On se retrouve donc avec 2 fois plus d'objets à gérer, qu'il faut biensûr faire communiquer ensemble.

- 3e défaut trouvé : Ce modèle implique aussi l'ajout d'objets supplémentaires : si je veux que mon header aille chercher des infos (métas, title, keywords) dans une BDD, il va me falloir là encore 2 classes. Idem pour le footer, s'il doit afficher des données dynamiques (par exemple le temps d'exécution d'un script, ou le nombre de visites).


Je passe les autres défauts qui pourraient exister, pour en venir à ma question.

- Est-il vraiment utile, concrètement, de séparer modèle et vue, dans un site, en sachant qu'avec le CSS, il on peux déjà personnaliser l'affichage grandement, sans avoir à diviser en 2 toutes les classes?

- En termes de réutilisation, le modèle objet permet déjà de créer des modules réutilisables (ce qui n'était pas forcément le cas de PHP4), avec des variables de classe etc. Le modèle MVC ne complique-t'il pas la chose inutilement? Il suffit de coder "convenablement" l'affichage, utilisant des balises appropriées, et de modifier le design par CSS. A la limite, on peux consevoir une fonction "affichage" dans sa classe, qui ne s'occuperait que de cela.

- L'utilisation des exceptions avec un modèle MVC est pour moi une énigme. En effet, une vue ne pouvant pas appeler de modèle, vu que le modèle est le plus propice à générer des exceptions (forcément, c'est lui qui fait le traitement), les exceptions seront forcément récupérées par le contrôleur. Or, ce n'est pas son rôle d'afficher une erreur (affichage->vue)!

Bref au final, j'ai un peu l'impression que le modèle MVC est comme son nom l'indique... un modèle, mais théorique, et pas forcément applicable. Cependant, je préfère vous demander votre avis, à vous qui avez peut être une autre vision de la chose, qui utilisez ce modèle, et qui avez peut être compris des choses que je n'ai pas compris.

Que pensez-vous de mon analyse? Suis-je dans le vrai?

[Taum]

Salut,

Tout d'abord je voudrais signaler que je n'ai que vaguement essayé d'appliquer le modèle MVC en PHP5 (quand je me suis initié au zend framework). En revanche j'ai commencé récemment ruby on rails, un framework qui est conçu pour exploiter largement le modèle MVC.

Maintenant pour répondre à tes interrogations :
1) Déjà je pense que le fait de penser que seul la vue change entre plusieurs sites est une erreur : ton premier exemple le montre bien. Si plusieurs sites ont besoin de fonction différentes, les controlleurs seront forcément différents (même si une partie des fonctionnalités sera surement commune). Si les données à manipuler sont différentes (par ex. la date dans un cas alors qu'on s'en fiche dans un autre cas) les modèles seront aussi différents.
Cela dit ce n'est pas parce que quelques fonctionnalitées changent que tout est à refaire à chaque fois.
Ou alors tu devras faire comme tu dis un "super module", dont l'inconvénient est forcément qu'il contiendra du code inutile pour ceux qui ne l'utiliserons pas a 100%.

2) Je vois pas trop ce que tu veux dire par là
Evidement si tu codes tout depuis le départ, c'est plus de travail. Cependant les relations controlleurs <-> vues devraient être gérées par le framework : ton controlleurs définies quelles variables sont disponibles, ta vues les utilises. Si tu as besoin de passer du temps pour mettre en place cette relation, il y a effectivement un problème quelque part


3) Alors là je suis completement perdu
Encore une fois c'est le rôle du controlleur de récuperer toutes les données de ta page et à la vue des les utiliser, je vois pas à quoi servent des classes header, footer ... ?


D'une manière globale, j'ai l'impression que tu essayes de concevoir un site avec l'architecture MVC en partant de rien. Si tu n'as pas de framework qui implémente cette architecture, effectivement c'est beaucoup d'énergie dépensée pour pas grand chose



Pour ce qui est des exceptions, voilà une manière de les gérer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class TrucController {
function actionMachin() {
  try {
    // Code du controlleur qui peut lever des exceptions
 
    $view->render(); // On appelle le template de base
  }
  catch (ErreurMachin $e) {
    $view->renderError($e->message); // On fait appelle un template spécial pour les erreurs
    // on pourrait aussi rediriger sur une autre page, etc...
  }
}
}

Certaines erreurs peuvent même être attrappées au niveau de l'application, pour être traitée de la même manière quelque soit le controlleur qui les génere.

Par exemple dans une appli Rails, mon modèle peut lever une erreur RecordNotFound si on lui demande de récuperer un objet qui n'existe pas. L'application attrape ces erreurs et affiche une page 404. En revanche, n'importe quel controlleur peut attraper cette erreur avant l'application (par exemple pour rediriger vers la liste des articles à la place). Je trouve ça a la fois simple et extremment puissant

[ChriGoLioNaDor]

D'une manière globale, j'ai l'impression que tu essayes de concevoir un site avec l'architecture MVC en partant de rien. Si tu n'as pas de framework qui implémente cette architecture, effectivement c'est beaucoup d'énergie dépensée pour pas grand chose

En effet, je n'utilise pas de framework, ce qui explique probablement ton incompréhension par rapport à mes questions. Je n'utilise pas de framework car je n'en éprouve pas vraiment le besoin : je les trouve beaucoup trop lourds (et puissants) pour ce que je veux faire, qui se veut justement le plus simple possible. De plus, qui dit framework dit formation, utilisation d'un composant que je ne maitriserais pas à 100% (forcément, je ne vais pas m'amuser à le décortiquer), et donc risque de problèmes au final

3) Alors là je suis completement perdu
Encore une fois c'est le rôle du controlleur de récuperer toutes les données de ta page et à la vue des les utiliser, je vois pas à quoi servent des classes header, footer ... ?

La raison est simple : dans mon header, je remplis les champs title, description et keywords. Or, ces données se trouvent dans une table de ma BDD, afin de pouvoir facilement les modifier via une interface utilisateur, par exemple. Or, ce n'est pas à ma vue ni à mon controleur de rechercher les données (d'après la description du modèle MVC) dans la BDD. Il me faut donc passer par un modèle (qui est représenté par ma classe "header"), qui ira faire la requête et retourner les données. Suite à quoi une vue (2e objet) "affichera" le résultat.


Si l'intérêt du MVC n'est pas d'avoir des modules réutilisables, quel est son intérêt? En effet, si je dois à chaque fois modifier ma vue, mon controleur, et mon modèle, j'ai du mal à voir pourquoi tout séparer. On ne peux pas dire que c'est pour séparer les taches, puisque tout est lié. Si je touche à mon modèle, je devrais très probablement modifier ma vue. Donc l'un et l'autre est lié.

Bref, j'ai vraiment du mal avec ce modèle! Mais merci d'essayer de m'éclairer Taum

[Taum]

La raison est simple : dans mon header, je remplis les champs title, description et keywords. Or, ces données se trouvent dans une table de ma BDD, afin de pouvoir facilement les modifier via une interface utilisateur, par exemple.

Dans ce cas précis, je verais plutôt ça comme de la configuration que réellement comme un modèle (un modèle étant lié au métier). J'aurais donc plutôt tendance à faire en sorte que la vue aille directement chercher les informations nécessaires à se configuration.
Mais encore une fois je n'ai pas une grande expérience du MVC donc peut-être qu'il existe des moyens de gérer ce type de cas en particulier ...



Quant aux frameworks voilà comment je vois les choses : je préferes passer 1h à chercher comment faire ce que je veux avec mon framework, que 2h à coder la fonctionnalité en question (voire plus car j'ai souvent tendance à vouloir faire trop d'abstraction).
Cependant je t'avoues qu'effectivement les quelques frameworks PHP que j'ai pu testé ne m'ont pas vraiment convaincu, et c'est en regardant d'abord vers Python (avec Django) puis vers Ruby (avec Rails) que j'ai réalisé l'interêt d'un bon framework. (je dois préciser que je n'ai jamais touché à Java (structs & co.))
Naturellement je n'utilise qu'une petite partie des possibilités offertes par le framework, mais je pense que c'est interessant ne serait-ce que pour la structure qu'impose l'utilisation d'un framework.

[ChriGoLioNaDor]

Tu vois, c'est justement pour des choses comme ça que j'ai du mal avec le MVC Ca me semble beaucoup trop abstrait pour être vraiment utilisable comme tel.

Par exemple, si j'affirme que ma vue est représentée par mon fichier CSS, tu ne peux pas vraiment me contredire : une vue n'est qu'un nom représentant une "couche" qui gère la mise en forme du contenu retourné par le modèle. Or, mettre en forme, c'est bien le boulot du CSS. Le HTML gère à structurer tes données, pas à les mettre en forme (du moins théoriquement). La preuve est que la présentation d'une même page varie d'un navigateur à l'autre. On a donc une structure fixe, et le navigateur qui se dit "tiens, là j'ai un titre, je vais le mettre en telle taille, en gras etc".

Idem pour la couche métier : certains préconisent de rajouter une classe d'abstraction de SGBD. Ca peut être utile en effet, mais en aucun cas cela ne fait partie du modèle MVC.

Enfin, le contrôleur. Il est sensé coordonner le tout. Mais d'un autre coté, je peux te dire que mon contrôleur, c'est mon serveur Apache, avec une redirection d'url qui redirige mon URL pour charger le fichier voulu. Ce dernier sera lui aussi considéré comme contrôleur, puisqu'il appellera ma classe (forcément, je suis bien obligé d'avoir un fichier pour appeler une classe objet :p)...

Bref au final, on a des notions très abstraites, qui bien qu'étant justes dans la théorie, peuvent se traduire de mille façons différentes, et à différents degrès de rapprochement par rapport à ce modèle. Ce qui est assez dommage, car pour moi, un modèle est justement quelque chose de concrêt, qui donne un exemple précis qu'il est conseillé de suivre. Quelque chose qui n'est que très peu soumis à interprétation.

[zyongh]

Personnellement, j'ai pris des semaines pour comprendre comment fonctionne le MVC et comment l'utiliser. Il est évident que le MVC ne sert à rien pour des petits modules. Par contre pour les gros projets... Je ne vois pas comment faire sans.

J'ai surtout l'impression que tu confonds le rôle de chaque élément et principalement Controller et Models. Ce n'est pas le controller qui est chargé de récupérer les variables mais le model.
Par exemple, tu fais un site de 100 pages ou plus en mélangeant dans le code Models et Vues. Puis tu veux ajouter une fonctionnalité qui devra être récupérer par une trentaine de pages. Tu dois modifier la trentaine de pages. Bonjour la galère!!! Maintenant le même site en MVC. Tu as juste à ajouter un model différent et il est pris en compte par les vues. Le Controller ne fait rien d'autre que mettre en relation la Vue sélectionnée et le Model qui a récupéré les données nécessaires (dans une BDD par exemple). Encore mieux, les modèles de conceptions ne se limitant pas aux MVC, tu peux sur cette option créer un décorateur. Et l'utilisateur ne sait jamais s'il utilise le véritable objet ou son décorateur.

Donc petit projet: MVC inutile
Gros projet: bien réfléchir avant de faire n'importe quoi.