Zend FR

Je crois que de toute manière il est primordial de contrôler toutes les valeurs saisies et de t'assurer qu'elles l'ont été correctement. Une valeur numérique ne peut pas être vide mais uniquement égale à 0 ou NULL.

Donc oui, il va falloir soit que tu surcharges les fonctions insert() et update() si tu utilises une classe d'accès pour ta table. Soit que tu parcours ton tableau afin de transformer ces valeurs.

il est du ressort du contrôleur de fournir au modèle des valeurs acceptable
c'est donc à lui de remplacer les chaines vide que fournis la vue en null s'il y a lieu

par défaut php garde les chaine vide comme des chaines il ne peut pas être omniscient pour faire des traductions dont il ignore le sens

sur un champs particulier la chaine vide peut être acceptable et significative alors que sur un autre la chaine vide venue de la vue doit être transformée en NULL

A+JYT

@sekaijin :

D'un point de vu "respect MVC" je suis tout à fait d'accord.

Pour des raisons plus pratiques, j'intègre systématiquement dans mes modèles une méthode de validation des données avant save().

Ca me permet de déplacer mes modèles et de ne jamais avoir à redéfinir ces choses là.

Mon controlleur lui, fait appel à une méthode d'une interface/façade et reçoit une réponse success ou non.

La façade déclenche le processus d'insertion du modèle, comme on l'aurait fait dans le controlleur. Le modèle renvoie une erreur si les données ne sont pas validées pour le save() et la façade ne fait que formater et transmettre le résultat de l'opération au controlleur.

Avant je faisais toutes ces validations dans le controlleur, mais j'ai décidé de procéder ainsi uniquement pour les modèles et pour me faire gagner de l'énergie.


Mis à part le respect du rôle de chacun du point de vue MVC, cette méthode te semble aberrante ?


A+ benjamin.

Delprog a écrit:

@sekaijin :

D'un point de vu "respect MVC" je suis tout à fait d'accord.

Pour des raisons plus pratiques, j'intègre systématiquement dans mes modèles une méthode de validation des données avant save().

Ca me permet de déplacer mes modèles et de ne jamais avoir à redéfinir ces choses là.

Mon controlleur lui, fait appel à une méthode d'une interface/façade et reçoit une réponse success ou non.

La façade déclenche le processus d'insertion du modèle, comme on l'aurait fait dans le controlleur. Le modèle renvoie une erreur si les données ne sont pas validées pour le save() et la façade ne fait que formater et transmettre le résultat de l'opération au controlleur.

Avant je faisais toutes ces validations dans le controlleur, mais j'ai décidé de procéder ainsi uniquement pour les modèles et pour me faire gagner de l'énergie.


Mis à part le respect du rôle de chacun du point de vue MVC, cette méthode te semble aberrante ?


A+ benjamin.

elle pose un  problème de portabilité de ton modèle
en déportant une partie du travail du contrôleur sur le modèle du créé une dépendance lorsque tu porteras ton modèle dans une autre application donc vers un autre contrôleur tu devra obligatoirement soit abandonner ce code déporté dans le modèle soit adapter ton contrôleur pour qu'il se comporte comme celui d'origine.

exemple
ton modèle défini les dates en interne dans un type qui lui permet de travailler (peu importe lequel)
dans ma première application qui travaille en français les dates sont échangées en français au format DD/MM/YYYY avec ton approche le modèle accepte une telle date en entrée et se charge de la filtrer la vérifier et la transformer dans sont format interne.
mais voilà que ton application va devoir aussi gérer les dates anglaises donc MM/DD/YYYY il et faut modifier ton modèle parce que ta vue à changée (dépendance des couches) mais pire tu ne sais pas distinguer
le 2 mars 2009 en français du 3 février 2009 en anglais 02/03/2009 la modification du modèle implique donc que le contrôleur lui fournisse en plus la langue de travail donc modification de l'API donc factoring de plusieurs partie de ton application. tu peux envisager de transformer la date avant de la donner au modèle mais alors il te faut la filtrer la valider (au sens syntaxique) la traduire pour la donner au modèle qui va la filtrer la valider (au sens syntaxique) puis la valider  sémantiquement.

pire ton modèle part dans une toute autre application ou tes dates à l'interface sont en japonais et en américain littéral soit donc D[kanji Jour)M(Kanji lune)YYYY et W YYYY, m D (Monday 2009 August 5)

là ton modèle n'est plus exploitable il faut lui redéfinir une API nouvelle

une autre approche
dans ton modèle tu use d'un format interne pour tes dates (privé) ton modèle défini une API qui accepte les dates comme étant des chaine au format YYYY/MM/DD
il ne se charge que le la validation sémantique
le contrôleur doit alors se charger de filtrer et de la validation syntaxique mais aussi si besoin de transformer la date pour que le modèle l'accepte.

pour cela tu peux par exemple te faire un plugin de contrôleur tu lui donne une chaine en entrée venant du formulaire et il te la filtre vérifie que c'est une date et te la retourne transformé pour le modèle

comme précédaient tu as travaillé en français et tu dois passer en anglais tu ajoute un méthode à ta classe de contrôle tu branche en fonction de la langue sur la bonne méthode de ta classe de contrôle tu ne touche donc pas à ton modèle

même scénario que précédemment tu place ton modèle dans une autre application qui cause nippon et américain dans cette nouvelle application tu place un pluggin contrôleur adéquat et ça marche

mieux tu peux utiliser le même pluggin et l'améliorer d'appli en appli tu à alors un pluggin gérant les problématique de dates de formulaire indépendant de tes modèles que tu vas pouvoir utiliser sur d'autres modèles

tu es donc gagnant sur toute la ligne

A+JYT

pour rester dans la théorie
la façade ne doit jamais porter de traitement

je maintient que valider syntaxiquement les données dans des plugin de contrôleur est bien plus portable que de le faire dans le modèle car ces plugin ne dépendent pas des modèles il ne dépendent que des type de données véhiculés
il sont donc transportable et peuvent évoluer pour capitaliser le travail.

et tout comme lorsque tu le déporte vers le modèle tu simplifie l'écriture du contrôleur
pour ma part je voit bien un contrôleur plus ou moins générique gérant les formulaire ainsi

if (this->validate($this->model->getUserDataPatern(), $data))
{
   $this->model->saveUser($data);
} else {
   ....
}

en clair j'ai un plugin chargé de valider le formulaire au niveau syntaxique il est le seul à pourvoir le faire car contrairement au modèle il connais lui la façon don la vue lui répond. par contre le modèle lui défini l'API si sais donc ce qu'il attend la méthode getUserDataPatern va dire qu'en entrée le modèle attend deux chaine une date et un entier et c'est la méthode validate du plugin du contrôleur qui va faire la vérification e tenant compte de son environnement
il peut alors donner les datas aux modèle qui lui va pouvoir le traiter vérifier la cohérence métier des données et par exemple les enregistrer.

la méthode validate est donc très générique elle a simplement besoin de connaitre le contexte c'est a dire quel sont les type de donnée attendus pas le modèle et le format des donnée reçus par de la vue.
cela se fait dans le plugin au moment de l'initialisation

au passage on peu avoir à valider un formulaire sans pour autant le donner immédiatement au modèle

par exemple lorsque je crée un utilisateur je ne quitte pas le formulaire tant qu'il n'est pas valide lorsqu'il est validé je propose la saisie d'un ou plusieurs profils que je valide aussi
lorsque tout est ok j'enregistre le tout en une seule transaction.

pour faire ça je suis obligé de faire deux méthode une pour valider une pour enregistrer

A+JYT