Zend FR

je passe par un modèle
le contrôleur n'a pas à connaitre la persistance du modèle

A+JYT

Merci pour vos réponses.

Ok, c'est effectivement plus propre au niveau séparation des couches d'avoir recours tout le temps à un modèle.
C'est juste qu'à un moment donné, pour une simple extraction, (genre un fetchAll sans condition) je trouvais ça superflu d'avoir une table qui renvoie les données à un modele qui lui même renvoie les données à un controleur (qui en plus renvoie à la vue)


Une autre question cependant, tjrs pour la bonne pratique :
Où se passent les opérations de vérification des données GET et POST, mettons avec des méthodes isXxxx() , dans le controleur ou dans le modèle ?

Merci dmathieu.

A plus tard pour les prochaines questions \o_

supertino7 a écrit:

Merci pour vos réponses.

Ok, c'est effectivement plus propre au niveau séparation des couches d'avoir recours tout le temps à un modèle.
C'est juste qu'à un moment donné, pour une simple extraction, (genre un fetchAll sans condition) je trouvais ça superflu d'avoir une table qui renvoie les données à un modele qui lui même renvoie les données à un controleur (qui en plus renvoie à la vue)


Une autre question cependant, tjrs pour la bonne pratique :
Où se passent les opérations de vérification des données GET et POST, mettons avec des méthodes isXxxx() , dans le controleur ou dans le modèle ?

deux choses dans les vérifs
le contrôleur doit s'assurer que ce qu'il envoie au modèle sont des données conformes à l'API du Modèle par exemple si le modèle attends un nombre en paramètre de la méthode c'est au contrôleur de s'assurer qu'il s'agit d'un nombre
de même pour les autres type de données les dates posant souvent problème je préconise toujours de définir une fois pour toute un type date pour le modèle c'est dans ce type que les échange se font avec le contrôleur.
ainsi on assure l'indépendance des couches. le contrôleur doit donc faire quelques contrôles et conversions.
c'est à lui d'assurer la transformation entre la vue et le modèle. et vice versa.

par contre il revient au modèle d'assurer les vérifications métiers. les vérification qui relève de l'applicatif et non de la mécanique mise en œuvre.

un exemple je pilote un moteur rotatif mon métier est une classe qui représente mon moteur et qui possède quelques méthodes comme stop start getRPM setRPM

face à ça j'ai une vue qui va me permettre de saisir une valeur qui représente la vitesse de rotation de mon moteur
lorsque un utilisateur saisie un valeur mon contrôleur la reçoit
la premier chose à faire est de la filtrer pour éviter les hacks
ensuite le contrôleur vérifie que la valeur saisie est un entier
puis il va la donner au moteur

l'opération est simple
mais mon moteur ne supporte pas les très haut régimes ni les très bas régimes il doit tourner entre 700 et 5500 rpm
ceci est une règle de fonctionnement de mon moteur c'est donc à la classe moteur de l'implémenter
verifyRPM qui vas retourner true si la valeur est ok false sinon

le contrôleur devient donc
filtrer pour éviter les hacks
ensuite le contrôleur vérifie que la valeur saisie est un entier
demander au moteur de vérifier la valeur
puis il va la donner au moteur

ainsi si je mets mon moteur dans une autre application j'ai la garantie que je ne perdrait pas de fonctionnalités

de même si je change de vue ou de contrôleur je pourrais toujours faire fonctionner correctement mon moteur

A+JYT