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.

[no-war]

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.

+1 aussi, je faisais comme cela avant. A peser le pour et le contre, je trouve qu'en terme de perf et de lisibilité du code, c'est moins à mon goût finalement, d'où cette réorientation.

- Les objets sont alourdis par toute la vérification (sommaire) des données, parfois conséquente.
- Les données peuvent se montrer "redondantes" entre modèles. Exemple :
J'ai un objet client qui va contenir quelques infos, au hasard : Son adresse, téléphone, email, ville, nom, prénom etcetc... Plus d'autres infos qui lui sont propres.
J'ai un autre objet utilisateur, qui n'a rien à voir avec mon objet client. Qui va contenir lui aussi une bonne partie des infos ci-dessus, en plus d'autres infos qui lui sont propre.

Gain de temps et de lisibilité :
- Un service s’exécutant avant l'appel des modèles permet de vérifier les données, quel que soit l'objet en dépendant.
L'action nécessite un traitement au préalable (ex fiche_civile.xml), c'est au service de s'en charger.
- Une grosse partie de la logique de vérification des données est dévolue à ce service.

Gain de performances : Certes le contrôleur gère les entrées sorties. Mais les données envoyées par un utilisateur ne font elles pas parti des entrées ? Si l'action attend d'instancier 15 modèles, autant faire un bon premier jet avant de le faire, surtout si des données invalides se retrouvent (et sont nécessaires) dans le 14ème modèle.

L'idéal est donc, à mon avis, cette sous-couche intermédiaire. Ni contrôleur ni modèle (du moins, et je suis d'accord avec toi, une partie, le "sommaire"), mais plutôt un "service". Le contrôleur continue l'exécution de l'action en fonction de ce que lui renvoie ce service, transmettant les données aux modèles etc. Ou alors redirige, change la vue etc directement, tout en économisant des ressources serveur...

Enfin la seule réelle vérité est certainement celle énoncée par Grunk, il y a plusieurs écoles :-)

[rawsrc]

Gain de temps et de lisibilité :
- Un service s’exécutant avant l'appel des modèles permet de vérifier les données, quel que soit l'objet en dépendant.
L'action nécessite un traitement au préalable (ex fiche_civile.xml), c'est au service de s'en charger.
- Une grosse partie de la logique de vérification des données est dévolue à ce service.

OK. Dans ton système qui connait l'existence de fiche_civile.xml (le contrôleur ou le modèle) ?

Si l'action attend d'instancier 15 modèles, autant faire un bon premier jet avant de le faire, surtout si des données invalides se retrouvent (et sont nécessaires) dans le 14ème modèle.

J'ai une approche de mon code par concepts et je dois t'avouer qu'il ne m'est jamais arrivé de jouer aux poupées russes.
A vrai dire, si l'action est tellement complexe qu'elle fait si massivement appel au modèle, il est d'autant plus invraisemblable qu'un contrôleur (en haut de la pile) sache ce qui va passer ou pas dans les tréfonds de l'application.

Dans ton approche et dans ce cas : tu crées un énorme fichier xml de contrôle pour l'action dans sa globalité (toutes sous-actions confondues) ?

[no-war]

OK. Dans ton système qui connait l'existence de fiche_civile.xml (le contrôleur ou le modèle) ?

C'est l'action. Un exemple (raccourci, je ne fais pas référence à la gestion des redirections/erreurs/succès etc...) :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?xml version="1.0" encoding="utf-8"?>
<behavior>
	<action name="ajouterClient">
		<service name="db" />
		<service name="upload" />
		<service name="dataManager">
			<check name="byGroupName/fiche_civil">
				<tag name="adresse" />
				<tag name="ville" />
				<tag name="code_postal" />
				<tag name="telephone" />
			</check>
			<check name="byActionName/client_holding">
				<tag name="nom_holding" />
			</check>
			<check name="byActionName/client_etab">
				<tag name="nom_etab" />
			</check>
		</service>
		<model name="client/client_holding">
			<method name="ajouterHolding" />
		</model>
		<model name="client/client_etab">
			<method name="ajouterEtab" />
		</model>
		<model name="client/client_contrat">
			<method name="ajouterContrat" />
		</model>
		<model name="client/client_contact">
			<method name="ajouterContact" />
		</model>
		<model name="client/client_equipement">
			<method name="ajouterEquipement" />
		</model>
	</action>
</behavior>

J'ai une approche de mon code par concepts et je dois t'avouer qu'il ne m'est jamais arrivé de jouer aux poupées russes.
A vrai dire, si l'action est tellement complexe qu'elle fait si massivement appel au modèle, il est d'autant plus invraisemblable qu'un contrôleur (en haut de la pile) sache ce qui va passer ou pas dans les tréfonds de l'application.

Dans ton approche et dans ce cas : tu crées un énorme fichier xml de contrôle pour l'action dans sa globalité (toutes sous-actions confondues) ?

Effectivement, l'exemple était un peu abusé, je voulais d'ailleurs le préciser.

Pour reprendre l'action (exemple non fonctionnel) ci-dessus. Elle englobe plusieurs actions qui peuvent toutes être indépendantes les unes des autres (tout dépend comment elles sont gérées, au bon vouloir).

On peut tout aussi bien créer un client de A à Z que créer seulement une "partie du client"... Gérer uniquement son contrat, son équipement etc...

Bref du coup le service fait appel aux fichiers xml demandés... Qui ressemblent à un truc comme :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<ville type="post">
	<method name="_isStr" params="min[2], max[20]" />
	<isEmpty error="La ville est obligatoire" />
	<isUnvalid error="Il semble que la ville ne soit pas au format attendu" />
</ville>
<telephone type="post">
	<method name="_isTel" params="tel_fr" />
	<isEmpty error="Le téléphone est obligatoire" />
	<isUnvalid error="Il semble que le téléphone ne soit pas au format attendu" />
</telephone>

PS : J'ai vraiment pris un exemple en bois, relativement rare, car idem j'évite les poupées russes également :-)