Bonjour tout le monde.
Depuis le temps que j'entends parler de MVC autour de moi et avec l'arrivée du ZendFramework, j'ai décidé de me mettre sérieusement à utiliser le modèle MVC afin de coder mon prochain site. Mais j'ai quelques soucis de compréhension concernant la partie Model et la partie Controller, les définitions que j'ai pu glaner sur le net n'était pas des plus explicites.
Afin de mieux comprendre, je souhaiterais partir d'un projet concret: Un wiki extremement basique.
Spécification du wiki:
- Une page est identifiée par un nom unique (lettres et chiffres, sans espace), elle a un auteur, une date de création, le nom du dernier auteur a l'avoir modifiée, la date de modification et peut comporter 0 à n commentaires
- un commentaire n'est pour qu'une seule et unique page, il a une date de création
- un auteur est défini par un login et un mot de passe
Fonctionnalités:
- affichage d'une page + commentaires associés + formulaire d'ajout de commentaire
- permet la modification d'une page
- identification des auteurs
Voila, bon, rien d'extraordinaire, je dirais meme, c'est le stricte minimum pour un wiki.
Maintenant voila ce que je ferais d'après ce que j'ai compris du MVC... mais comme je me doute que je dois me tromper, c'est pour ca que je vous le soumé pour que vous me donniez vos avis.
MODEL
Pour moi le Model, c'est "un objet".
En l'occurence, là, je ferais un objet pour page, un autre pour commentaire et enfin un 3eme pour user.
C'est la que je gérerais les différentes actions qu'on peut y faire.
Page (add, update, get)
Comment (add, get)
User(add, get)
Bon, en réalité, ca serait certainement un peu plus poussé, genre pour Page, y'aurais certainements une fonction pour avoir chaque type d'info, le titre, le contenu, les dates, l'auteur, un truc pour savoir combien y'a de commentaires, etc...
CONTROLLER
Pour moi, le controller est un peu le chef d'orchestre. Bon déjà y'a le FrontController qui dispatch ce que l'utilisateur à envoyé comme info pour aller chercher le bon controller. Une fois qu'on est dans le bon controller, d'après ce que j'en ai compris, c'est lui qui va instancier des models, faire les calculs, les traitements, etc.... puis enfin, appeler la view qui-va-bien
Dans ce cas présent je ferais les choses comme ca:
PageController:
- view: récupère le contenu de la page et les différents commentaires de la base
- edit: récupère le contenu de la page de la base
- add: récupère les données du formulaire pour les insérer en base
CommentController:
- add: récupère les données du formulaire pour les insérer en base
UserController:
- login: récupère les données du formulaire pour les tester avec les données de la base
VIEW
La vue, je dirais que c'est la partie la plus simple. C'est ni plus ni moins qu'un template. Ca récupère les données que lui envoit le controller pour les afficher (bon en fait, je serais tenté de dire que c'est pas tout a fait exact parce que la vue, ca pourrait aussi etre la vue d'un serveur xml-rpc, donc ca n'affiche rien, ca ne fait qu'envoyer des données formattées, en fait..)
Voila, ma vision des choses:
- page_view: affiche contenu de la page + différents commentaires + formulaire d'ajout d'un commentaire
- page_edit: affiche un formulaire pour modifier le contenu de la page
- user_login: affiche un formulaire de connexion pour que l'user s'identifie
- éventuellement différentes vue pour avoir un ensemble homogene tel que header, footer, menu, etc...
CONCLUSION ?
Résultat des courses? je me fourvoie completement?
la communauté d'entraide francophone dédiée au PHP
Compréhension et application de MVC
salut,
si biensur. T'as plutôt bien intergré le principe.
Pour préciser un peu. Le modèle n'est pas forcement un objet pour reprendre ta phrase, ni un groupe d'objets, c avant tout toute la logique métier qui entre autres s'occupe d'appeler la couche de services techniques (acces bd) pour mettre à disposition les données ou les ecrire.
Le controller: suivant les appli on peut choisir de créer un seul ou plusieurs contrôller. L'ideal je pense que c plusieurs mais parfois un seul est suffisant. Son rôle c'est de gerer tous les evenements systemes décrits ds les cas d'utilisation et les diagrammes de séquence systeme.
Là tu décris differents evenements déclenchés par le clients à gérer ds le controller, c plutôt bien.
Pour la vue je crois que tu as compris aussi. Pour préciser encore, ds un systeme purement objet, le controller donne à la vue les references des objets dont elle a besoin et c à elle d'aller chercher ce qu'elle veut ds le modèle.
Ca donne un peu plus de responsabilité à la vue que tu ne le décris. Ceci dit avec php, le tt objet n'est pas tout à fait possible encore, donc c à toi d'adapter un peu tout ça en essayant autant que possible que chaque partie ne fasse pas plus ni moins que ce qu'elle devrait.
si biensur. T'as plutôt bien intergré le principe.
Pour préciser un peu. Le modèle n'est pas forcement un objet pour reprendre ta phrase, ni un groupe d'objets, c avant tout toute la logique métier qui entre autres s'occupe d'appeler la couche de services techniques (acces bd) pour mettre à disposition les données ou les ecrire.
Le controller: suivant les appli on peut choisir de créer un seul ou plusieurs contrôller. L'ideal je pense que c plusieurs mais parfois un seul est suffisant. Son rôle c'est de gerer tous les evenements systemes décrits ds les cas d'utilisation et les diagrammes de séquence systeme.
Là tu décris differents evenements déclenchés par le clients à gérer ds le controller, c plutôt bien.
Je pense que tu as compris mais le controller demandera au modèle de lui donner ou d'enregistrer ttes ces données, il le fera pas lui même.pour les insérer en base
Pour la vue je crois que tu as compris aussi. Pour préciser encore, ds un systeme purement objet, le controller donne à la vue les references des objets dont elle a besoin et c à elle d'aller chercher ce qu'elle veut ds le modèle.
Ca donne un peu plus de responsabilité à la vue que tu ne le décris. Ceci dit avec php, le tt objet n'est pas tout à fait possible encore, donc c à toi d'adapter un peu tout ça en essayant autant que possible que chaque partie ne fasse pas plus ni moins que ce qu'elle devrait.
Zend propose une implémentation assez sympa du modèle MVC dans son framework, sur Zend Framework, a practical tutorial.
Typiquement le modèle est le coeur de l'application : c'est lui qui accède aux données, les envoie au contrôleur qui les manipule (appels éventuels au modèle pour enregistrer les modifications sur les données), et les envoie à la vue qui se contente d'afficher. C'est très bien rendu dans ce tutorial. Tu es tout-à-fait dans la bonne optique.
Typiquement le modèle est le coeur de l'application : c'est lui qui accède aux données, les envoie au contrôleur qui les manipule (appels éventuels au modèle pour enregistrer les modifications sur les données), et les envoie à la vue qui se contente d'afficher. C'est très bien rendu dans ce tutorial. Tu es tout-à-fait dans la bonne optique.
Bon, ben ca me rassure tout ca 
Oui, je suis au courant pour le Zend Framework, c'est précisemment pour ca que je veux donner une tournure résolument MVC à mes futurs développements, en utilisant Zend Framework autant que faire se peut. Néanmoins, il est très buggué et pas encore tout à fait au point, je patiente donc encore un peu
Oui, je suis au courant pour le Zend Framework, c'est précisemment pour ca que je veux donner une tournure résolument MVC à mes futurs développements, en utilisant Zend Framework autant que faire se peut. Néanmoins, il est très buggué et pas encore tout à fait au point, je patiente donc encore un peu
En fait, c'est surtout que j'avais mal compris quelque chose qui me faisait penser que c'était buggé... mais en fait, pas du tout
J'ai donc commencer le développement de ce wiki qui ne me sert qu'à appréhender la bête. Je mettrais les sources une fois terminé
J'ai donc commencer le développement de ce wiki qui ne me sert qu'à appréhender la bête. Je mettrais les sources une fois terminé