Discussion :

[RunCodePhp]

Bonjour à tous

Je tente de m'initier à ce concept MVC (donc Model Vue Controller), mais je patauge un peu dans la choucroute particulièrement entre le Controller et le model.

Pour faire court, je tente de donner un exemple simple et assez proche de la réalité : Une identification par exemple.

D'abord, il y a un routage qui ce fait dans le index.php, donc tout demande de page, comme identification.html passera en 1er dans ce index.php, le point d'entrée.
Ensuite, dans le index.php on inclus le controller :

Code :

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

1
2
3
4
5
6
7
/**
 * index.php
 */
// Une succession d'initialisation, d'instanciation
$route = $conf::getRouteur(); // Instancie le routeur
$route->routage();
require('controllers/'.Routeur::$page['name']);// Correspondra à identification.php ici

Puis le controller (identification.php) se charge donc à inclure le model et la vue, mais d'exécuter les actions aussi (d'après ce que j'ai compris).
En résumé, ça se traduit comme ceci :

Code :

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
 
/**
 * CONTROLLER identification.php
 */
$session = Session::getInstance();
$session->start();
$href = $Conf::getLink();
$user = User::getInstance();
 
// Inclure le model
require('models/'.Routeur::$page['name']); // Correspondra à identification.php ici
 
// Récurér les données / Les stocker / faire les actions
if (isset($_POST['action']) && ($_POST['action'] === 'identifier')) {
    // Phase d'identification
}
 
// Inclure la vue
require('vues/template.php'); // Le template inclus les vues, les blocs, entre autre identification.php

Le model se charge de récupérer les données

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
/**
 * MODEL identification.php
 */
require(Template::loadLangue());
require(Template::loadPageLangue());
 
 
$template->addLinkCss('formulaire.css');
$template->addLinkJS('verif_formulaire.js');
$template->addLinkJS('identification.js');

Le problème c'est que je ne sais pas trop quand include le model : avant de faire les actions dans le controller ou après ?
D'un coté, il faudrait ici que ça soit fait avant à cause du contenu linguistique, car s'il y a une erreur, il est nécessaire d'avoir le message avant une redirection.
De l'autre, en cas d'erreur toujours, j'aurais chargé $template pour rien.
Ce n'est qu'un exemple, il y en a d'autres des comme ça.
Bref ... je tourne en rond.
Disons que j'ai tendance à vouloir tout mettre dans le controller, et le model ferait office de vue plus qu'autre chose.


Bon, je suis en phase intermédiaire, je prospecte le MVC avec ce que j'ai actuellement, mais j'ai l'impression que c'est le souk.
Je ne parviens pas à faire le distingo entre le controller et le model, ce qu'ils doivent contenir ou faire.

Vous en pensez quoi de cette organisation, structure ?
Faut il tout revoir ?

Merci

[grunk]

Sans trop m'avancer (parce que je bosse plus avec un mvc maison que dans les règle de l'art) et en gardant ton exemple d'identification :

Ton model seras par exemple une classe qui gèrera toutes les données de l'utilisateur

Code :

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

1
2
3
4
5
6
7
 
class identification
{
   public function getLogin(){}
   public function getGroupe(){}
   ....
}

Ton controller lui va effectivement inclure ton model et l'utiliser mais également transmettre les données à la vue et charger la vue au moment voulue.

Code :

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

1
2
3
4
5
6
 
require('mon_model.php')
$id = new Identification();
$login = $id->getLogin();
$template->login = $login;
$template->show('login.html');

[Fladnag]

En principe :

* Le modèle correspond aux données
* La vue correspond a l'organisation des données sur la page
* Le contrôleur fait le lien entre les deux et gère tout le reste ;o)

A priori ce que tu as c/c me parait bien... sauf pour le modèle.

Que viennent faire des templates dans le modèle ? La gestion du multi langage et les templates devraient se trouver dans la vue selon moi.

Dans le modèle tu as uniquement les données, c'est a dire la connexion a la base de données, la récupération, mais pas la mise en forme pour l'utilisateur (tu peux avoir une mise en forme pour le controleur cependant, pour lui renvoyer un joli objet et pas une ressource DB a moitié parsé ^^)

PS : coquille corrigée ^^

[BornBanane]

* Le modèle fait le lien entre les deux et gère tout le reste ;o)

Petite coquille.
Lire contrôleur et pas modèle dans cette ligne.

[RunCodePhp]

Code :

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

1
2
3
4
5
6
class identification
{
   public function getLogin(){}
   public function getGroupe(){}
   ....
}

C'est ce que j'ai fait il me semble, car même si ce n'est pas Objet, l'action "identification" pourrait évoluer comme tu le démontre.
Enfin, je pense.
Ceci dit, comment faudrait il voir l'Objet qu'on obtiendra, plutôt coté controller ou du model ? (coté organisation).
Vu que les appel se font dans le controller, je dirais donc coté controller.

A priori ce que tu as c/c me parait bien... sauf pour le modèle.

Que viennent faire des templates dans le modèle ? La gestion du multi langage et les templates devraient se trouver dans la vue selon moi.

C'est aussi l'impression que j'ai, que ça ne devrait pas être là.
Ca, il me semble pouvoir corriger ça assez facilement.
Mais dans mon exemple, le model contiendrait plus rien, et c'est ça qui me semble bizarre.

mais pas la mise en forme pour l'utilisateur (tu peux avoir une mise en forme pour le controleur cependant, pour lui renvoyer un joli objet et pas une ressource DB a moitié parsé ^^)

Que veux tu dire par la mise en forme ?
Dans le controller, je débute par une instance de User. (il ne contient rien à ce stade)
Mais après, c'est vrai que l'initialise, suite à l'action "identifier".
En gros, je vérifie que les données en POST soient bonnes, vérifie sa présence dans la Bdd, puis si tout est Ok, l'Objet User contiendra ses données, entre autre identifié.
Que faudrait il faire au niveau du modèle ici ?

[Fladnag]

Ce que je veux dire c'est que dans le modèle tu peut récupérer les données et construire un objet pour les mettre dedans.

La partie mise en forme de la donnée sera faite dans la vue

Par exemple si ton modèle contient un montant, en php tu récupère un simple float et c'est la vue qui détermine a combien de décimale tu l'arrondi, si tu affiches € derrière, etc...

La partie validation des données devrait être faite dans la contrôleur selon moi. Que ce soit pour vérifier qu'une donnée soit présente (donc niveau "contrôle de surface") ou pour vérifier une règle de gestion complexe.

Tu pourrais donc avoir :

Code :

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

1
2
3
4
5
6
7
* Appel du controleur
   * Recuperation du modèle
   * Si les controles sont corrects
      * Utilisation de la vue "OK" avec le modèle
   * Sinon
      * Soit une redirection vers une autre page (donc un autre appel de controleur)
      * Soit directement utilisation d'une vue "KO" avec le modèle

[RunCodePhp]

Par exemple si ton modèle contient un montant, en php tu récupère un simple float et c'est la vue qui détermine a combien de décimale tu l'arrondi, si tu affiches € derrière, etc...

Ok, je vois.
Je ne cache pas que ce n'est pas cas, du moins, pas toujours, va me falloir y penser donc.
Ca va être chaud.
Mais on peu créer une méthode dans la classe User, et l'appeler dans la vue, non ?
Genre : User::getMontantEuro() qui mettra les entités HTML sur l'euro.
Est ce correcte ? (exemple bidon, mais on s'en fiche).

La partie validation des données devrait être faite dans la contrôleur selon moi. Que ce soit pour vérifier qu'une donnée soit présente (donc niveau "contrôle de surface") ou pour vérifier une règle de gestion complexe.

Ici, théoriquement c'est respecté.
Dans l'exemple que j'ai mis, la phase d'identification se fait dans le controller (après avoir inclus le model), donc les données en POST et toute la logique/règles.

[Fladnag]

tu peux avoir une methode getMontantEuro() dans User a condition d'avoir une autre méthode getMontant() qui ne t'ajoute pas &euros;

En fait le but c'est d'éviter d'avoir a toucher au modèle si tu veux afficher tes données différemment.

Donc je dirais tu peux faire des méthodes de formatage dans le modèle si elles sont assez complètes et assez évolutives, sans aller jusqu'a faire une méthode du genre :

Code :

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

1
2
3
function getMontantDecore(/* String */pTemplate) {
  return str_replace("MASQUE", this.getMontant(), pTemplate)
}

Par contre tu devrais pouvoir faire :

Code :

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

1
2
3
function getMontantDecore(pNbDecimales=2, pAvecEuro=FALSE) {
  return number_format(this.getMontant(), pNbDecimales).((pAvecEuro)?" €":"");
}

Attention tout de même a être light sur ce genre de méthodes ;o)

[grunk]

En gros, je vérifie que les données en POST soient bonnes, vérifie sa présence dans la Bdd, puis si tout est Ok, l'Objet User contiendra ses données, entre autre identifié.
Que faudrait il faire au niveau du modèle ici ?

La partie validation des données devrait être faite dans la contrôleur selon moi. Que ce soit pour vérifier qu'une donnée soit présente (donc niveau "contrôle de surface") ou pour vérifier une règle de gestion complexe.

Vérifier les GPC dans le controller je suis d'accord , par contre vérifier la présence dans la bdd relève à mon avis du modèle (on appellera la méthode adéquat depuis le controller, mais la tache à proprement parlé est effectué par le model)

En tout cas c'est comme ça que je procède. A partir du moment ou j'intéragie avec une bdd , un fichier , ... => model.
Après en ce qui concerne les données retournées et leur traitement c'est plus délicat, mais en général je retourne des données brutes et les traites dans les controllers afin d'avoir des model réutilisables le plus simplement possible.

[Fladnag]

on est d'accord, je parlais d'une vérification GPC ;o)

Le modèle peut vérifier que les données qu'il extrait et qu'il renvoie au controleur sont cohérentes, si cela n'est pas effectué par la base elle meme avec des contraintes