Discussion :

[Invité]

Bonjour,

Je me posais une question.

Le contrôleur est censé vérifier les données avant d'envoyer les infos au modèle.
Mais on m'a dit que le modèle devait vérifier/contrôler les données lui même car si jamais on crée un autre fichier utilisant ce modèle, on devra crée un autre contrôleur.
Du coup le modèle contrôle les infos ? On met les try catch également dans le modèle ?

Quelqu'un peut me confirmer cela ?

[Celira]

Je suppose qu'on peut mettre une méthode validate dans le modèle qui vérifie les choses vraiment basiques (du genre le champ "bidule" ne doit pas être null) qu'on peut appeler quand on a besoin de valider les données.
En revanche, c'est le contrôleur qui exploite les erreurs renvoyées par la méthode.

[jouana]

Ton model vérifie et valide la cohérence des données pcq c'est lui qui les connais réellement cette partie
Ton controleur lui applique les règles qui sont propres à la vue.
Et comme dit plus haut la gestion des erreurs sur la page.

[grunk]

C'est un point délicat du MVC, personne n'est vraiment d'accord et il y'a plusieurs école :

- Nettoyage dans le controller :
L'avantage est que les données sont tout de suite filtrées et du coup ne sont plus dangereuse pour l'application.
Une même données pourra être passée à 2 modèles différents sans dupliquer la validation.

Le problème étant que si un autre controller utilise un modèle , il faudra bien penser à dupliquer la validation.

On va avoir des controllers un peu plus gros

- Nettoyage dans le model :
Tu prend les arguments précédents et tu inverses
Ton modèle va contenir du code qui n'ai pas vraiment de la logique métier.

- Nettoyage dans le dispatcher/router
Présente le très gros avantage d'intercepter et filtrer les données avant toutes introduction dans l'application. Semble compliquer à mettre en place pour avoir quelque chose de souple.


Perso je fait un mix du controller et du model :
Le controller filtre les données à coup de filter_input afin de m'assurer que la données est ce que j'attends (une string , un entier ...). je vais pas lancer un model alors que les paramètres attendus ne sont clairement pas bon et ne correspondent à aucune erreur metier.

Puis dans le model je rentre dans le spécifique :
Mon entier est il bien compris dans les bornes attendus , mon email ne comporte t'il pas un domaine bannis ...
Dans ce cas , si erreur il y'a , je suis capable de lever une exception claire et précise sur la problématique métier.

Dans tous les cas tu sera amener à faire du filtrage dans le controller selon la vue puisque le model ne sait pas si les données qu'il retourne seront du xml, de l'html , du json, etc... ce sera donc au controller d'adapter le nettoyage au format de sortie.

[no-war]

C'est un point délicat du MVC, personne n'est vraiment d'accord et il y'a plusieurs école :

+1

Bonjour,

Codant un framework MVC depuis pas mal de temps maintenant, je suis pas mal d'accord avec Grunk !

On ne lance pas un model si les paramètres attendus ne sont pas les bons (quelle que que soit l'école j'aurais tendance à dire)

Perso, j'utilise 2 contrôleurs. Le contrôleur du projet (primary controller, gestion des events), qui instancie (entre autre) un service qui s'occupe de nettoyer/valider ce qu'attend l'action. Les données sont invalides, on modifie la vue. Les données sont valides, un secondary controller (gestion des actions) exécutent le(s) modèle(s) de l'action...

Ça implique une dépendance mais la ré-utilisabilité du code est présente, un ou plusieurs modèles = un ou plusieurs xml contenant les données (nom des champs, type attendu, éventuellement un code/phrase d'erreur etc...)... Suffit de reprendre le service de validation dans un autre projet, l'instancier par un contrôleur et le tour est joué.

[rawsrc]

Bonjour,

Personnellement, je considère le contrôleur comme un point d'entrée/sortie et de ce fait il ne vérifie uniquement que les paramètres d'appels soient correctement définis.
Du fait de l'encapsulation, le contrôleur ne connait pas à vrai dire ce qui est nécessaire au bon déroulement de l'action. L'action est la plus autonome possible et remonte le cas échéant les erreurs au contrôleur qui s'adapte en conséquence. Sous réserve de la validité des paramètres d'appels, je lance quoi qu'il arrive l'action (qui fait sa vie, oserais-je dire).
Je fais surtout attention à ne pas pas marcher sur les plates bandes du métier au niveau du contrôleur.

Perso je fait un mix du controller et du model :
Le controller filtre les données à coup de filter_input afin de m'assurer que la données est ce que j'attends (une string , un entier ...). je vais pas lancer un model alors que les paramètres attendus ne sont clairement pas bon et ne correspondent à aucune erreur metier.

J'ai arrêté d'éparpiller les contrôles sur plusieurs niveaux. Cela améliore la robustesse du code. Sans compter que les contrôles (sommaires) des données faits au niveau du contrôleur vont être totalement refaits au niveau du métier...

Enfin je pense qu'il n'est pas judicieux de présumer de la complexité de l'action au niveau du contrôleur.