Séparer le modèle du controleur

Bonjour, vous m’excuserez, j’ai posté ce message sur yiiframework.fr mais il n’y a pour l’instant personne pour me répondre.

Bon, je débute dans l’utilisation du modèle MVC, j’espère un peu de compassion de votre part ::)

Je suis un train de faire des essais tous bêtes:

Un site avec une liste d’items et une photo pour chaque item.

Je me pose une question: où doit-on traiter (déplacer, redimensionner etc) l’upload? Dans la Controller::actionCreate() ou dans le modele::maFonctionUploadeImage(); ???

Je vois par exemple que dans la démo Blog, les emails sont envoyés directement via SiteControler.




/**

	 * Displays the contact page

	 */

	public function actionContact()

	{

		$model=new ContactForm;

		if(isset($_POST['ContactForm']))

		{

			$model->attributes=$_POST['ContactForm'];

			if($model->validate())

			{

				$headers="From: {$model->email}\r\nReply-To: {$model->email}";

				mail(Yii::app()->params['adminEmail'],$model->subject,$model->body,$headers);

				Yii::app()->user->setFlash('contact','Thank you for contacting us. We will respond to you as soon as possible.');

				$this->refresh();

			}

		}

		$this->render('contact',array('model'=>$model));

	}



Et que le modèle ContactForm ne contient quasiment rien.

C’est un exemple pour une question générale finalement. Je ne comprends pas très bien la logique de séparation du code. Sur un site bien équipé en fonctionnalités, le controler “SiteControler” va contenir un paquet de lignes.

Alors, en théorie ? On les met où tous ces bouts de codes qui se chargent d’enregistrer, envoyer un email, vérifier ci ou ça dans la base etc… ?

Salut Clem,

dans ton exemple, je placerai effectivement les traitements dans le controller.

Alors tu as raison, un controller peu rapidement devenir très très gros, mais si c’est le cas, il te faut peut-être séparer les traitements dans plusieurs controller.

Dans le cas ou certains traitements sont identiques pour différentes actions, Yii permet de définir une action comme une classe à part entière, réutilisable donc, dans plusieurs controller.

Enfin, tu peux aussi décider de créer un composant dédié pour effectuer certain traitements sur tes données, tes modèles. En tout état de cause, un modèle ne devrait être utilisé que pour représenter des données, pas pour les traiter. Dans le cas du ContactForm, il faut distinguer les données du formulaire (sujet,texte,etc…) des traitements appliqués sur ces données (ici l’envoie par email). Certes le modèle ContactForm est un peu vide, mais il existe plein d’autres exemples ou le modèle contient pas mal de code : la validation des entrées, et dans le cas d’un ActiveRecord des traitements spécifiques au stockage dans un DB, etc…

j’espère avoir été clair, mais si ce n’est pas le cas n’hésite pas à poster ;)

ciao

8)

Merci pour ta réponse. C’est un peu plus clair, mais pas limpide.

J’essaye de voir la relation avec les classes que j’utilisais auparavant, sans modèle MVC.

Avant j’avais une classe avec les méthodes associées (create, update, delete etc).

Cette classe, finalement c’est un contrôleur? Pour moi le contrôleur ne faisait que distribuer les ordres. Mais d’après toi, c’est lui qui les exécute, mais avec l’aide du modèle…

Bref, c’est là que je coince, entre ce que fait le controleur et le modèle.

Pourquoi mettons la méthode afterDelete dans le modèle et le delete dans le controleur?

[color="#1C2837"][size="2"]

.[/size][/color]

[color="#1C2837"][size=“2”]C’est bien ça.[/size][/color][color="#1C2837"][size=“2”]Le controlleur effectue des traitements comme la collecte des données en entrée (envoyées par l’utilisateur mais aussi depuis la base de données) et il créé (render) des vues, et éventuellement d’autres modèles.[/size][/color]

[color="#1C2837"][size=“2”]Le modèle, contient les données issues d’un formulaire ou de la BD, ainsi que les méthodes permettant d’accèder à ces données, de les modifiers, valider, sauvegarder. Dans un modèle ne dispose que des méthodes qui sont spécifiques à son type.[/size][/color]

[color="#1C2837"][size="2"]Enfin la vue est produite par le controller à partir des données reçues en entrées (données utilisateur ou depuis la BD).[/size][/color]

[size="3"][color="#1C2837"][size="2"]

[/size][/color][/size]

[size=“3”][color="#1C2837"][size=“2”]Oui, le contrôleur est un peu comme le chef d’orchestre. Tu peux bien sûr placer des traitements dans ton modèle, mais il devrait s’agir de traitement hyper spécifiques. Par exemple l’envoi d’un mail est une opération qui n’a pas a être implémentée dans un modèle, mais dans un composant spécifique (qu’on pourrait appeller MailManager par exemple) qui sera utilisé par le contrôleur lorsque ce sera nécessaire. Ce composant (classe) [/size][/color][/size][color="#1C2837"][size=“2”]MailManager proposerait une méthode acceptant en entrée tel ou tel type de modèle.[/size][/color]

[size="3"][color="#1C2837"][size="2"]

[/size][/color][/size]

[size="3"] [/size]

[size=“3”][color="#1C2837"][size=“2”]La méthode afterDelete est un gestionnaire d’évènement qui est invoqué de façon automatique par Yii, après qu’un modèle AR (CActiveRecord) ait été effacé de la BD. Elle peut être utilisée par exemple pour supprimer toutes les photos associées à un item qui vient d’être effacé de la BD.[/size][/color][/size]

[size=“3”][color="#1C2837"][size=“2”]Quant à l’autre méthode delete présente dans le contrôleur … humm je ne sais pas à quoi tu fais référence, mais il devrait s’agir d’une méthode répondant à une demande utilisateur.[/size][/color][/size]

[size="3"] [/size][size="3"] [/size]

[size=“3”][color="#1C2837"][size=“2”]8)

[/size][/color][/size]

Excellent, merci! Des réponses comme ça valent des heures de recherche ! Je ne réponds que maintenant n’ayant pas reçu de notification…

Très bonne journée à tous.

Il semble que tu ne sois pas le seul à poser des questions sur MVC, et dans le prochaine release Yii, la doc sera mise à jour avec un chapitre qui traite de ce sujet.(en anglais) ;)

ciao

8)

Pour faire très bref:

Le controlleur s’occupe de gérer la logique au niveau de ton application.

Le modèle s’occupe de gérer l’abstraction avec les données de ton application.

Et les vues s’occupent de générer le visuel.

En bonus, je me rappelle une expression qu’un sénior m’avait donnée un jour:

"Keep in mind, fat models and skinny controllers" (Souviens toi, gros modèles, et controlleurs minces).

En espérant t’aider :)

A+

Effectivement, il n’y a pas de règles strictes pour le traitement des données. Je viens de m’en rendre compte en créant une administration.

Mon application possède un seul modèle pour gérer l’actualité par exemple, et deux controleurs, un pour le site et l’autre pour l’admin, du coup certains traitements se retrouvent logiquement dans un controleur en particulier et d’autres, utilisables par les deux, dans le modèle.

J’arrive un peu tard, mais il semble qu’ActiveRecord est point déconseillé lorsque la base de données est chargée pour causes de ralentissements.

Cf (http://code.google.com/p/yii/source/browse/trunk/docs/guide/topics.performance.txt?r=2672)