Discussion :

[keaton7]

Bonjour,

Je me pose une question sur la vérification de mes champs. Je développe une application dans un contexte MVC, et j'hésite à vérifier mes champs dans le contrôleur (comme son nom l'indique), ou dans mon modèle (qui ne devrait pas laisser entrer n'importe quoi).

Vous faites comment vous ? Vous contrôlez dans vos contrôleurs ? Où ce dernier ne sert qu'à dispatcher ?

Merci d'avance pour vos avis experts

[grunk]

J'effectue les contrôles dans le contrôleur pour ma part. J'ajoute éventuellement des controles sur le type des données (type hinting) dans le modèle mais pas plus.

[rawsrc]

J'effectue les contrôles dans le modèle pour ma part
Le contrôleur dans mon cas ne sert qu'à orchestrer le déroulement du programme et à gérer les appels en fonction des différents retours.

[Doopeijii]

Le principe du MVC c'est que le contrôleur ne fasse que la liaison entre la vue et le modèle. Le modèles lui se charge de tous les traitements. Normalement c'est donc dans le modèle, puisque le contrôleur ne traite pas les données. Mais c'est défendable, c'est un peu à l'appréciation de chacun

[keaton7]

Merci pour vos réponses, en fait elles sont le reflet de ce que j'ai vu un peu autour de moi, et qui fait que je me pose aujourd'hui cette question.

Certains entendent contrôle dans controller au sens de vérification, et font en sorte de nettoyer les éléments envoyés aux modèles, qui sont censés dans cette logique ne faire QUE leur travail (au sens métier).

D'autres en revanche, entendent contrôle au sens de "pilotage", et ne font dans le contrôleur que les opérations basiques d’exécution (du dispatch process).

Je me demandais d'après ces 2 approches, quelle est celle, la plus puriste peut être, mais aussi la plus commode, car il n'est pas question de complexifier l'appli à cause d'un Design Pattern dont le rôle est justement inverse ...

[Benjamin Delespierre]

Il y a autant d'interprétations du MVC que de développeurs qui l'implémentent, donc au final c'est à toi de voir.

Traditionnellement, il est d'usage de déléguer l'intégralité des opérations de contrôle de données au sein du contrôleur. La raison est simple: seul le contrôleur dispose d'une vue d'ensemble de la requête HTTP en cours, c'est donc lui le mieux placé pour prendre une décision si une données est incorrecte.

Tu trouvera de tout, certains te diront que c'est au modèle de vérifier les données, d'autres qui te diront que les modèles ne vérifient rien et se contentent d'écrire, c'est plus une histoire de goûts et de couleurs (et surtout une belle querelle de clocher). Donc fait ce qui te semble adéquat tant que les contrôles en question ne se font pas dans la vue bien entendu

[rawsrc]

A mon avis, il est quand même préférable de rendre le modèle autonome.

A vrai dire, lorsque vous avez une tâche complexe qui nécessite de multiples appels entres briques logicielles, le contrôleur ne peut raisonnablement pas s'assurer qu'une donnée soit valide dans la énième brique logicielle. A cela vous pouvez rajouter que certaines briques peuvent très bien transformer les données et là je peux vous garantir que les tests dans le contrôleur ne seront d'aucune utilité.

Pour un simple traitement, pas de problème, le contrôleur peut se charger des contrôles des données métier mais pour le reste, cette tâche incombe au modèle.
Par ailleurs, si vous développez sur des gros projets, les appels de modèle à modèle sont généralement très fréquents, sans intermédiaire au milieu, le modèle doit se débrouiller seul.

Pour bien comprendre, il faut voir le contrôleur comme un point d'entrée de l'application à partir de l'extérieur. Rien de plus. Le contrôleur pilote le déroulement de l'application et son rôle doit être très limité.

Enfin, si vos règles métiers changent et si vous faites vos tests dans le contrôleur, il faudra également penser à le modifier.
Bref, d'après tout ce que j'ai pu coder, je peux vous assurer qu'il est bien plus propre de déporter la validation des données métiers dans le modèle.

Après, comme le souligne Benjamin Delespierre, il y a la tradition ou la mode du moment que bien évidemment personne (avec un peu de réflexion) n'est obligé de suivre.

Bonne cogitation.