IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PHP & Base de données Discussion :

Model View Controller


Sujet :

PHP & Base de données

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Invité
    Invité(e)
    Par défaut Model View Controller
    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 ?

  2. #2
    Modératrice
    Avatar de Celira
    Femme Profil pro
    Développeuse PHP/Java
    Inscrit en
    Avril 2007
    Messages
    8 633
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeuse PHP/Java
    Secteur : Industrie

    Informations forums :
    Inscription : Avril 2007
    Messages : 8 633
    Par défaut
    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.
    Modératrice PHP
    Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur)
    Cherchez un peu avant poser votre question : Cours et Tutoriels PHP - FAQ PHP - PDO une soupe et au lit !.

    Affichez votre code en couleurs : [CODE=php][/CODE] (bouton # de l'éditeur) et [C=php][/C]

  3. #3
    Membre très actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2010
    Messages
    434
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2010
    Messages : 434
    Par défaut
    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.

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 693
    Par défaut
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2013
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2013
    Messages : 45
    Par défaut
    Citation Envoyé par grunk Voir le message
    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é.

  6. #6
    Expert confirmé
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Billets dans le blog
    12
    Par défaut
    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.

    Citation Envoyé par grunk Voir le message
    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.

Discussions similaires

  1. Model View Controller
    Par RomG7 dans le forum Débuter avec Java
    Réponses: 0
    Dernier message: 09/02/2011, 07h58
  2. Model View Controller
    Par kazuzu dans le forum Débuter avec Java
    Réponses: 1
    Dernier message: 14/05/2010, 17h10
  3. Model view controller exemple en java
    Par startx25 dans le forum Débuter avec Java
    Réponses: 3
    Dernier message: 16/04/2010, 16h35
  4. Réponses: 2
    Dernier message: 11/02/2010, 21h09
  5. Architecture Model-View-Controller 2
    Par womannosky dans le forum Langage
    Réponses: 11
    Dernier message: 26/06/2008, 16h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo