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.

[keaton7]

Merci pour vos réponses.

D'après ce que vous me dites, je pense que je vais faire des filter_input à minima dans mes contrôleurs, et garder les vérifications de types (is_array, is_null, etc.) dans mes modèles pour traiter les valeurs attendues par le métier. Ca me parait à peu près cohérent, dites moi si je me trompe ^^.

[Benjamin Delespierre]

Je trouve que c'est une assez bonne façon de faire, attention seulement à ne pas faire de doubles vérifications.

[rawsrc]

Merci pour vos réponses.

D'après ce que vous me dites, je pense que je vais faire des filter_input à minima dans mes contrôleurs, et garder les vérifications de types (is_array, is_null, etc.) dans mes modèles pour traiter les valeurs attendues par le métier. Ca me parait à peu près cohérent, dites moi si je me trompe ^^.

Je pense que c'est pas le mieux : tu vas éparpiller les responsabilités.
La cohérence voudrait que tu rassembles ces traitements. Je te déconseille de tester un bout de tes données à un endroit et le reste à un autre.
C'est le meilleur moyen pour faire des doublons.

[keaton7]

Ok, donc je vais ptet pencher pour un filter_var dans mon modèle finalement, même si faite un $Modele->methode($_GET['bidule']) me fait mal au coeur ^^

[rawsrc]

Ok, donc je vais ptet pencher pour un filter_var dans mon modèle finalement, même si faite un $Modele->methode($_GET['bidule']) me fait mal au coeur ^^

Ne le fais pas si tu as mal au coeur.
Tu sais, ce n'est que de la programmation, pas une séance de torture

Et puis tu peux très bien te créer un objet qui va encapsuler toutes les variables. Objet instancié et rempli par le contrôleur avant d'être envoyé dans le monde inconnu du modèle.
Bref, tu as d'autres moyens à ta disposition.

[keaton7]

Non mais ça me paraissait logique en fait, donc pas de soucis Et loin de moi 'idée de créer des classes juste pour me soulager ... je hais la "complexification" gratuite

[rawsrc]

Si je t'ai dit ça c'est parce que j'utilise moi-même ce système au sein de mon framework. En déportant la validation des données dans le modèle, tu vas être très vite confronté à un problème de taille : comment remonter à la surface (càd jusqu'au contrôleur) les différentes erreurs que tes variables pourraient générer au sein du modèle.
Sachant qu'au point d'entrée de l'application, le contrôleur ne connait pas la cascade des tâches que le modèle va réaliser pour satisfaire sa demande.

Si tu veux au jouer au Sherlock, je te laisse mariner.

[keaton7]

Bah avec un try/catch autour de l'execution du framework ($framework->run()) dans l'index, je m'en sors tout à fait avec les erreurs. Il me suffit d'émettre des exceptions dans mes modèles. Ou alors j'ai pas bien compris ce que tu voulais dire

[rawsrc]

Bah avec un try/catch autour de l'execution du framework ($framework->run()) dans l'index, je m'en sors tout à fait avec les erreurs. Il me suffit d'émettre des exceptions dans mes modèles. Ou alors j'ai pas bien compris ce que tu voulais dire

Cette approche a des grosses limites et n'est pas exploitable en l'état.
Je m'explique : suppose qu'un de tes formulaire avec 10 champs poste ses 10 variables. Le contrôleur fait son boulot, appelle le modèle en lui passant les variables. Chaque variable est testée par le modèle et tu décides de tirer une exception dès la première erreur rencontrée.
L'exception va rediriger automatiquement le flux de l'exécution vers le catch { } et que fais-tu des variables envoyées mais non vérifées ? Tu va les renvoyer sans indiquer leur validité ? Perte de temps non ? Tu dois penser à tout valider à chaque passage de manière à signaler les valeurs qui sont rejetées. Ce sont des tests courants et non des exceptions.

[rawsrc]

Si tu déportes toutes les validations dans le modèle et que le contrôleur en est déchargé, il faut encapsuler tes valeurs dans un objet te permettant la récupération des erreurs au fur et à mesure du voyage dans le monde du modèle. De cette manière le contrôleur va garder un lien (une référence) avec les données en provenance du monde extérieur et saura quoi faire après inspection des variables au retour du flux d'exécution.

Après des tas d'essais, je peux te garantir que c'est l'approche la plus souple et simple.

[keaton7]

Oui, pour les try catch, je ne pensais pas aux formulaires, mais plutôt aux paramètres attendus par mes modèles. Les formulaires, je vais ptet bien créer une classe spé pour ça en effet