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

[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

[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)

[RunCodePhp]

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.

Ok, je vois bien pour le getMontant() et getMontantEuro().

Cependant, il y a un truc pas clair.
L'Objet User est un modèle, disons que je veux bien.
Mais concrètement, cet Objet est instancié dans le controller, de même que les données sont initialisées toujours dans le controller, de plus, le fichier (User.php) ce trouve dans un répertoire "classes" (avec toutes les classes).
En somme, il y a rien le concernant au niveau du model (le fichier models/identification.php).
Du coup, j'ai du mal à concevoir que cet Objet soit un modèle, tout porte à croire que c'est un controller.
Est-ce normal, est-ce si abstrait que ça, où il y a t-il une erreur de conception dans mon exemple ?


Autre point que je n'est pas évoqué, c'est la connexion de la Bdd, et elle se fait dans le index.php.
Donc ni dans le modèle ou j'ai lu que ça devrait l'être, et encore moins dans le contrôleur.
Actuellement, j'ai besoin quelle se fasse dans le index.php car toutes les pages sont dans la Bdd, et le Routeur vérifie que la page demandée existe bien.
Est ce correcte comme principe ? Respecte t-il le concept MVC ici ?

[grunk]

Autre point que je n'est pas évoqué, c'est la connexion de la Bdd, et elle se fait dans le index.php.
Donc ni dans le modèle ou j'ai lu que ça devrait l'être, et encore moins dans le contrôleur.
Actuellement, j'ai besoin quelle se fasse dans le index.php car toutes les pages sont dans la Bdd, et le Routeur vérifie que la page demandée existe bien.
Est ce correcte comme principe ? Respecte t-il le concept MVC ici ?

Ton index.php est bien un controller , plus spécifiquement un frontController (celui recoit toutes les infos et les redispatch aux sous controllers).

La connexion Bdd est en principe une classe situé dans tes modèles, sauf si évidement tu utilise directement un truc du genre mysqli ou pdo auquel cas c'est un peu plus particulier.

[Fladnag]

Pour la classe User pour moi elle fait partie du modèle.

Schematiquement on a :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
== Controleur ==
Récupération des parametres de la requete
Appel du modele avec les parametres de requete HTTP si nécessaire
== Modele ==
Connexion a la base
Récupération des données
Construction de l'objet User a partir des données
== Controleur ==
Vérification des données de l'objet User
Appel de la vue en lui passant User
== Vue ==
Construction de la page avec l'objet User (avec des templates, du multi-langage, etc...)
== Controleur ==
Renvoi la vue

En pratique on va souvent récupérer plusieurs types d'objet dans la base, donc on va appeller plusieurs modele. Il est souhaitable alors de déporter la connexion a la base dans le controleur pour le faire une fois pour toutes.

Tu peux aussi laisser la connexion dans le modèle en utilisant le pattern Singleton, comme ca tu ne te connecte que la 1ere fois.

[RunCodePhp]

@grunk
Effectivement, le terme me revenait plus. Le index.php est le FrontController.

Pour la connexion Bdd ... Ouf
Je me voyais mal faire autrement.
C'est bien PDO, et un singleton (Je sais, il y en a qui sont en croisades contre les singletons )

Pour la classe User pour moi elle fait partie du modèle.

Pour mois aussi, mais finalement, c'est très abstrait, voir complètement, car il y a pas grand chose, même rien qui dit que tel ou tel Objet (classe) est un modèle plus qu'un contrôleur.

Est-ce que le fait d'instancier des Objets dans le controller (ici controllers/identifications.php) ce sera inévitablement des modèles ou des vues ?
Ou est-ce qu'il est possible (ou permis) d'instancier d'autres controllers ?


En faite, ma question est toujours la même, qu'est ce qui distingue vraiment un Objet modèle et controleur ?
Le simple fait que l'un contient des données (model), l'autre (controller) des vérifications, de la logique, du déroulement ?

Pour l'Objet Session par exemple.
A priori ce serait un modèle, car celui ci contient des données Utilisateur, la session.
Mais dedans, au niveau des méthodes, il y a tout de même de la logique, des vérifications, genre si le cookie de session est correcte.
Où est-ce ni l'un ni l'autre, juste une librairie ?


Les questions fusent, je sais, mais quand c'est pas clair, c'est pas clair

[Fladnag]

Pour moi le modèle c'est les données qui viennent d'une ressource externe.

Donc la session ne fait pas partie du modèle je pense, elle est dans le controleur !

Le controleur n'instancie pas d'"Objet Modele" (par exemple User) mais il peut instancier des "Modele" (classe Modele dont une méthode va renvoyer un objet User)

Oui un controleur peut instancier d'autres controleurs. Typiquement lorsque tu redirige vers une autre page ou si tu veux scinder une logique complexe en plus petits controleurs

Le Modele doit contenir le moins de vérifications possibles, son rôle est de porter les données pour le controleur.

[RunCodePhp]

== Controleur ==
... etc ...
== Modele ==
... etc ...
== Controleur ==
... etc ...
== Vue ==
... etc ...
== Controleur ==

Si je résume ceci comme un déroulement, on pourrait quelque part éviter d'avoir un fichier "model" inclus dans le controller (comme dans mon exemple : models/identification.php), mais faire essentiellement appel aux méthodes ou autres instanciations concernant les ou les models, non ?
Ou faut il obligatoirement inclure un fichier model ?

Quand je regarde les mofifs que j'ai appliqué (très rapidement certes), concernant le code qui se trouve dans les fichiers des modèles respectifs à chaque page, tout devrait aller soit du coté du controleur, soit de la vue, donc plus rien dedans.
Ca me parais bizarre tout ça.


J'en est lu des trucs, et comme ça sur le papier ça à l'air logique, mais quand je regarde mon code, et tente de le modifier pour le rendre plus conforme dans ce concept MVC, c'est plus du tout la même chose.
C'est d'un compliqué j'vous dis pas.


Petite question subsidiaire.
Quel est le Soft MVC en Php5 (Open Source) le plus simple (basique même) à prendre en main ?
J'ai entendu parlé de Code Igniter, ça me parais balaise quand même.
J'ai téléchargé Kohana, je le parcours (j'fais l'espion ), c'est un peu chaud encore.
Le truc que j'ai tenté il y a peu, c'est CakePhp. Je me suis cassé les dents dans les grandes largeurs. Il y a des règles de tarés à respecter. L'angoisse
Zend ou Synfony, c'est même pas la peine ...


En tout cas, merci pour ces nombreux retours.

[Petibidon]

C'est bien PDO, et un singleton (Je sais, il y en a qui sont en croisades contre les singletons )

Vous m'appelâtes ?

Perso le MVC avec PHP, je suis pas super convaincu. De par le fonctionnement du langage, et par la séparation "naturelle" du traitement et de la présentation. Autant il est toujours possible de faire de la bouillie de PHP/HTML, autant je pense qu'avec un minimum d'expérience, on en arrive à toujours séparer le traitement des données et leur affichage. De la même manière qu'on arrive très rapidement à limiter la complexité de son HTML en s'appuyant sur CSS.

Par contre je suis en train d'étudier un peu l'usage du pattern strategy dans une idée qui se rapproche un peu du MVC. C'est assez intéressant, mais reste à voir à l'usage si c'est aussi prometteur que mes tests (pour le moment succincts) le laissent paraitre.

[Fladnag]

Pour moi tu n'a pas besoin d'inclure des "fichiers modèles", tu peux appeler des "méthodes de modèle" et des "méthodes de vues", c'est toi qui voit ;o)

Je ne connait pas les logiciels MVC du marché, je ne peux pas t'en parler. Le seul truc que j'avais trouvé sympathique dans ces systèmes c'est les templates Smarty que j'avais trouvé relativement puissants ^^ même s'ils t'obligent à apprendre (presque) un deuxième langage. Après ca fait super longtemps que je me suis intéressé au problème (~ 2007) ça a eu le temps de changer depuis !

[Madfrix]

Zend ou Synfony, c'est même pas la peine ...

Je te conseilles Zend

Certes : c'est pas simple. Après pas mal de lecture de tutos tu arrives à produire quelque chose de sympa. Le truc c'est qu'il est très souple dans son utilisation, tu peux parvenir à 1 résultat de 1000 facons possibles ce qui en fait sa force et sa faiblesse (du moins au début). J'aime particulièrement son système d'autoloader de classes et de paramètrage via un fichier .ini même si jedoute pas que les autres frameworks disposent de tels outils.

Actuellement, j'essaie d'interfacer zend et flash via amf et je patauge un peu mais bon c'est en forgeant qu'on devient forgeron comme qui dirait l'autre (d'ailleurs si quelqu'un connait un bon tuto sur zend_amf et flash je suis preneur. Attention pas flex^^).

[s.n.a.f.u]

Petite question subsidiaire.
Quel est le Soft MVC en Php5 (Open Source) le plus simple (basique même) à prendre en main ?
J'ai entendu parlé de Code Igniter, ça me parais balaise quand même.
J'ai téléchargé Kohana, je le parcours (j'fais l'espion ), c'est un peu chaud encore.
Le truc que j'ai tenté il y a peu, c'est CakePhp. Je me suis cassé les dents dans les grandes largeurs. Il y a des règles de tarés à respecter. L'angoisse
Zend ou Synfony, c'est même pas la peine ...

Je n'ai pas de conseil à te donner car ils ont tous leurs avantages et leurs inconvénients.
Je suis un fervent utilisateur de ZF, mais pour les petits sites j'aime bien CI.
Et je pense me mettre à Symfony dès que j'en ai le temps, surtout depuis que j'ai appris qu'ils vont se concerter avec Zend pour faire converger les deux frameworks vers une logique commune.

Quoi qu'il en soit, ces frameworks te donnent une réponse à ta question initiale : "ça dépend"
Les concepts de controller, de model et du rôle de chacun dans l'appli est assez différente dans ces familles de frameworks et le principal est de coller à l'esprit de l'appli existante.