Discussion :

[Reelo]

Bonjour à tous

Juste une petite question sur l'organisation d'un projet en MVC.

Si on a un projet découpé, dans mon cas, en deux parties (une privée, pour l'administration (elle même découpée en 5 services de gestion par ex gestion de stocks, comptabilité, préparation de commandes etc... ) et l'autre publique, pour la réalisation d'achats en ligne, création d'un compte client par ex), avec chaque parties ayant leurs propres pages (par ex le service des stocks à une page d'accueil, une page pour visualiser un stock, une autre pour saisir des produits à mettre en réserve etc..Faut-il un contrôleur par service ou bien un contrôleur par page ? Actuellement j'utilise 5 contrôleurs (un par services, ControleurGestionStocks, ControleurPrepaCommandes ....) et un pour la partie publique. Ça commence à faire un peut désordre.
Je me demande donc s'il ne vaudrait mieux pas en faire un par page pour qu'il soient moins longs (mais plus de fichiers au final). Quand pensez vous et surtout comment fait on en général ?

[CinePhil]

Je ne trouve pas que ça fasse désordre.

Un contrôleur est une classe et une classe est destinée à faire une chose, même si elle contient plusieurs méthodes pour bien faire cette chose.

Mon architecture des fichiers est la suivante (je n'utilise pas de framework) :

|-Application
|--Ajax (pour stocker les programmes PHP appelés par les fonctions Javascript Ajax)
|--Config
|--Controller (pour y stocker les classes contrôleurs génériques Controleur, Modele, Configuration, ErrorCollection, Routeur...)
|--i18n (pour les fichiers de traduction en différentes langues avec un sous répertoire par langue)
|--Model (pour toutes les classes modèles)
|--Modules (parce que l'application est, comme la votre, séparée en plusieurs modules)
|---[Module1]
|----Controller (pour stocker les contrôleurs du module 1
|----View (pour stocker les vues du module 1)
|---[Module2]
|----Controller (pour stocker les contrôleurs du module 2)
|----View (pour stocker les vues du module 2)
|-logs
|-Public
|--css (pour y stocker les fichiers css)
|--img (pour y stocker les fichiers image)
|--jquery (pour y stocker la bibli JQuery et ses accessoires)
|--js (pour y stocker les fichiers javascript)

Il est probable que j'aurai au final plusieurs dizaines de contrôleurs mais comme c'est bien rangé, pas de souci.

A titre d'exemple, j'ai actuellement :
- un module Accueil avec 3 contrôleurs (Accueil, Connexion, Deconnexion) ;
- un module Inscription avec 5 contrôleurs (Ajouter, Importer, Inscription, Lister, Modifier).

Les contrôleurs Accueil et Inscription sont évidemment les contrôleurs principaux de leur module respectif. Les autres sont appelés lors d'actions sur les pages affichées par ces contrôleurs principaux.

Jusque là, cette manière de faire me convient.

[grunk]

En général je considère que un controller = une fonctionalité.

Le code des controllers doit rester léger puisque de toute manière le code "compliqué" va se retrouver dans les modèles.

[CinePhil]

puisque de toute manière le code "compliqué" va se retrouver dans les modèles.

Pas forcément...

Pour moi, le modèle, c'est l'accès aux données. Ça reste généralement simple. Le contrôleur est là pour... contrôler ! Et son code peut devenir ainsi plus compliqué.
Et si une partie d'une classe modèle devient compliquée parce que, par exemple, elle enregistre des données dans plusieurs tables suite à la même requête HTTP, il peut devenir très intéressant de passer en développement en base de données épaisses.

Pendant mes vacances, j'ai développé une fonction/procédure PostgreSQL qui permet d'enregistrer un nouvel utilisateur de type élève :
- la procédure fait le boulot de répartir correctement les données dans 7 tables ;
- la méthode de la classe modèle Eleve fait simplement appel à la fonction en quelques lignes de code en lui passant les données.

[Reelo]

Bonsoir;
Zuuut ! je m’aperçois que j'ai raté plein de trucs.

On dirait qu'il y a autant de structures MVC qu'il y a de jours dans l'année
En ce qui me concerne je ne cherche pas à faire un truc trop complexe. Pour l'instant c'est juste pour voir comment ça se combine. Comme Cinephil je n'utilise pas de framework (c'est, pour moi, l' étape d'après, enfin j'espère quand j'aurais bien tout compris)
En fait j'ai réfléchi et j'ai opté pour un contrôleur par page. ça fait plus de fichiers au niveau des contrôleurs.
Mais il sont plus courts.
je mets mon organisation des fichiers ça sera plus clair.

• dossier contenu
  
  • css
  • images

• dossier Controleur
  
  • fichiers des différentes classes controleur + routeur

• dossier Modele
  
  • dossier entites
    
    • fichiers représentant les classes des entités de la bdd
  
  
  • fichiers des différents manager pour l'accès à la bdd

• dossier Vue
  
  • dossier pour les vues publiques
  
  
  • dossier pour les vues privée (administration)
  
  

• index.php

ça reste modeste et pas très évolué et c'est certainement perfectible. En fait le plus dur, est je crois, de savoir quel type de découpage à adopter. Peut être que découper en modules avec chacun des controleurs et les vues adéquates, comme CinePhil serait une bonne solution, je n'y avais pas pensé.

[rawsrc]

Salut,

Pour moi, le modèle, c'est l'accès aux données. Ça reste généralement simple. Le contrôleur est là pour... contrôler !

Attention à ne pas accorder trop de responsabilités au contrôleur qui du coup va empiéter sur le modèle.

Je vous rappelle qu'un contrôleur dans le MVC n'a qu'un rôle de filtre. Je m'explique : prenons un cas concret : vous réalisez une action de persistance via une route avec soumission de formulaire : vous allez récupérer une Url paramétrée et des valeurs via $_POST. Jusque là, rien d'extraordinaire. Maintenant voyons le traitement MVC côté serveur :
- l'url reçue devra être décortiquée afin de trouver précisément quel bout de code serait susceptible de traiter la requête (en gros, l'url dans le navigateur doit correspondre à une route dans le serveur)
- supposons que l'url corresponde bien à une route et qu'à cette route est rattaché un contrôleur. Le principe est simple : toute action dans votre application doit exposer un contrôleur unique qui servira de porte d'entrée aux données de l'extérieur. Il faut limiter la portée du contrôleur. Les contrôles effectués par le contrôleur s'arrêtent à la vérification d'un environnement d'exécution correspondant à l'action. Pour schématiser il faut vous dire que pour réaliser une action dans l'application, le modèle aura besoin de la présence de certaines variables et sous une certaine forme. A ce stade, le contrôleur ne vérifie pas le contenu des variables, juste leur existence, la vérification de la validité des variables relève du modèle. Par exemple, si vous obfusquez certaines valeurs dans les url, ça sera au contrôleur d'essayer de les désobfusquer afin de les présenter en bonne et due forme au modèle pour le traitement suivant.
Ainsi vous préserverez l'indépendance des couches du MVC.

[CinePhil]

Je ne vois pas de contradiction entre ce que tu préconises et ce que je fais.

Exemple d'une connexion à l'application...

1) L'utilisateur clique sur le lien "Me connecter" de la page d'accueil qui a pour URL : monAppli/fr/Accueil/Connexion.

2) Via le .htaccess, l'URL est transformée en : monAppli/index.php?langue=fr&module=Accueil&action=Connexion.

3) index.php appelle le routeur :

Code :

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

1
2
3
4
5
/**
 * Lancement du routeur et appel de l'action demandée ou par défaut
 */
use Application\Controller\Routeur;
Routeur::getInstance()->appelerAction();

4) Le routeur récupère dans $_REQUEST, via son constructeur, la langue, le module et l'action appelée puis la méthode appelerAction vérifie l'existence du module et de l'action et appelle le contrôleur correspondant :

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
	/**
	 * Instancie le contrôleur requis et lance l'action demandée s'ils existent
	 */
	public function appelerAction()
	{
		if($this->verifierModule() && $this->verifierAction())
		{
			$classeControleur = 'Application\\Modules\\'.$this->getModule().'\\Controller\\'.$this->getAction();
			$controleur = new $classeControleur($this->getLangue(), $this->getParametres());
			$controleur->index();
		}
		else 
		{
			// Module ou action inexistante renvoie vers la page d'accueil
			$this->gererErreur();
		}
	}

5) C'est donc le contrôleur Connexion du module Accueil qui est lancé (fichier Application/Modules/Accueil/Controller/Connexion.php et sa méthode index :

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
	/**
	 * Affiche le formulaire vierge ou lance le traitement de la connexion
	 */
	public function index()
	{
		if(empty($_POST))
		{
			// Affichage du formulaire de connexion vierge
			$this->afficherPageConnexion();
		}
		else
		{
			// Traitement du formulaire
 
	}

6) Durant le premier passage, $_POST est vide et le contrôleur se contente d'afficher le formulaire de connexion qui contient ceci :

Code html :

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

<form id="login" action="fr/Accueil/Connexion" method="post">

=> Écart peut-être par rapport à ce que tu as écrit : je rappelle la même URL que pour afficher le formulaire de connexion vierge.

7) L'utilisateur a rempli (ou pas, ou mal) le formulaire de connexion et clique sur le bouton "Me connecter".

8) Le même contrôleur est donc rappelé et cette fois $_POST existe et on passe par le traitement du formulaire de connexion :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
		else
		{
			// Traitement du formulaire
			/** 1) Vérifier les données saisies */
			$this->verifierFormulaire();
 
			/** 2) Vérifier l'existence de l'utilisateur */
			$username = trim($_POST['username']);
			$password = trim($_POST['password']);
 
			// Recherche de l'utilisateur dans la BDD et récupération de ses informations
			$objUtilisateur = new Utilisateur();
			$result = $objUtilisateur->getUserByLogin($username);
 
			if(empty($result))
			{
				// Utilisateur inexistant
				ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Utilisateur inexistant')); // TODO i18n
 
				// Réaffichage du formulaire de connexion
				$this->afficherPageConnexion();
			}
 
			/** 3) Vérifier le mot de passe de l'utilisateur */
			if($objUtilisateur->isUtiLdap() == true)
			{
				// Vérification via LDAP
				$ds = ldap_connect(Configuration::getParam('ldap_host'));
				ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
				$util = ldap_bind($ds, 'uid='.$username.','.Configuration::getParam('ldap_base_dn'), $password);
				ldap_close($ds);
 
				if(!$util)
				{
					// Mauvais mot de passe par rapport au LDAP
					ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Mauvais mot de passe (LDAP) !')); // TODO i18n
 
					// Réaffichage du formulaire de connexion
					$this->afficherPageConnexion();
				}
			} // Fin de if($utilisateur->getUtiLdap() == true)
			else 
			{
				// Utilisateur non LDAP => on vérifie son mot de passe dans la BDD
				if(!$objUtilisateur->verifieMotPasse($password))
				{
					// Mauvais mot de passe par rapport à la BDD
					ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Mauvais mot de passe (BDD) !')); // TODO i18n
 
					// Réaffichage du formulaire de connexion
					$this->afficherPageConnexion();
				}
			} // Fin du else de if($utilisateur->getUtiLdap() == true)
 
			/** 4) Vérification que l'utilisateur est valide */
			if($objUtilisateur->isUtiValide() != true)
			{
				// Si utilisateur invalide -> Refus de connexion avec message d'erreur
				ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Utilisateur invalide !')); // TODO i18n
 
				// Réaffichage du formulaire de connexion
				$this->afficherPageConnexion();
			}
 
			/** 5) Connecter l'utilisateur */
			$this->connecter($objUtilisateur);
		} // Fin du else de if(empty($_POST))

9) La méthode verifierFormulaire se contente de vérifier que les champs ont été renseignés :

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
20
21
22
23
24
25
	/**
	 * Vérifie les données saisies par l'utilisateur dans le formulaire de connexion
	 */
	private function verifierFormulaire()
	{
		if(empty(trim($_POST['username'])))
		{
			ErrorCollection::getInstance()->ajouterErreur(new \ErrorException("Vous devez saisir votre nom d'utilisateur.")); // TODO i18n
		}
		else
		{
			$this->setLogin(trim($_POST['username']));
		}
 
		if(empty(trim($_POST['password'])))
		{
			ErrorCollection::getInstance()->ajouterErreur(new \ErrorException('Vous devez saisir votre mot de passe.')); // TODO i18n
		}
 
		if(count(ErrorCollection::getInstance()->getListeErreurs()) > 0)
		{
			// Erreur(s) trouvée(s) => on réaffiche la page de connexion avec erreur
			$this->afficherPageConnexion();
		}
	}

10) La vérification de l'utilisateur utilise le modèle Utilisateur a plusieurs endroits :

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
			// Recherche de l'utilisateur dans la BDD et récupération de ses informations
			$objUtilisateur = new Utilisateur();
			$result = $objUtilisateur->getUserByLogin($username);
// ...
 
			/** 3) Vérifier le mot de passe de l'utilisateur */
			if($objUtilisateur->isUtiLdap() == true)
// ...
 
				// Utilisateur non LDAP => on vérifie son mot de passe dans la BDD
				if(!$objUtilisateur->verifieMotPasse($password))
// ...
 
			/** 4) Vérification que l'utilisateur est valide */
			if($objUtilisateur->isUtiValide() != true)

11) Si tout va bien, la connexion de l'utilisateur utilise encore le modèle Utilisateur :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
	/**
	 * Connecte l'utilisateur à l'application
	 * @param object $utilisateur
	 */
	private function connecter(Utilisateur $utilisateur)
	{
		// Démarrage de la session utilisateur
		session_start();
 
		$_SESSION['userId'] = $utilisateur->getIdentifiant();
		$_SESSION['login'] = $this->getLogin();
		$_SESSION['userNom'] = $utilisateur->getNomUsuel();
		$_SESSION['userPrenom'] = $utilisateur->getPrenom();
		$_SESSION['userValide'] = $utilisateur->isUtiValide();
		$_SESSION['langue'] = $this->getLangue();
		$_SESSION['uri'] = Routeur::getInstance()->getUri();
 
		// Récupération de ses droits d'accès
		$fonctions = $utilisateur->getFonctionsUtilisateur();
 
		// Construction du tableau des droits de l'utilisateur
		$listedroits = array();
 
		foreach ($fonctions as $key => $value)
		{
			$listedroits[] = $value['fonctionCode'];
		}
 
		$_SESSION['droits'] = $listedroits;
 
		// Récupération de ses menus
		$menus = $utilisateur->getMenusUtilisateur();
 
		// Construction du tableau des menus de l'utilisateur
		$listemenus = array();
 
		foreach ($menus as $value)
		{
			$listemenus[$value['menuCode']]['libelle'] = $value['menuLibelle'];
			$listemenus[$value['menuCode']]['parent'] = $value['menuParent'];
			$listemenus[$value['menuCode']]['ordre'] = $value['menuOrdre'];
			$listemenus[$value['menuCode']]['actif'] = $value['menuActif'];
			$listemenus[$value['menuCode']]['module'] = $value['menuModule'];
			$listemenus[$value['menuCode']]['action'] = $value['menuAction'];
		}
 
		$_SESSION['menus'] = $listemenus;
 
		$page = new Page('Bienvenue');
		$page->addCssFile('Public/css/menu.css');
		$page->afficherPage();
	}

Donc mon contrôleur :
- a contrôlé que le formulaire est rempli ;
- a contrôlé l'utilisateur (existe, a ce mot de passe, est valide) en utilisant les méthodes du modèle Utilisateur ;
- a connecté l'utilisateur en utilisant encore des méthodes du modèle Utilisateur.

Mon code n'est peut-être pas top parce que je suis encore quelque peu débutant en PHP objet mais je pense avoir respecté les principes de séparation du modèle et du contrôleur.

[grunk]

Pas forcément...

Pour moi, le modèle, c'est l'accès aux données. Ça reste généralement simple. Le contrôleur est là pour... contrôler ! Et son code peut devenir ainsi plus compliqué.

On à juste pas la même notion de "compliqué". Pour moi le controleur n'est pas compliqué dans le sens où comme tu le dis c'est juste du contrôle de données. Les modèles eux contiennent le code métier et c'est pour moi ce code qui est compliqué. Pas forcément compliqué dans le sens difficile à écrire , mais compliqué dans le sens qu'il faut la connaissance du métier pour l'écrire.
Savoir quel champ d'une bdd aller lire ou écrire c'est compliqué, vérifier que 100 champs de formulaire soient remplis ou qu'une requête http est bien formé ça ne l'est pas (pour moi).

Ca me vient d'un des projets que je créer et maintient depuis quelques années qui s'interface sur un ERP qui possède plus de 1000 tables et n'a pas d'API . Même si certains controller peuvent être imposant , la vraie difficulté se trouve dans le code métier (pourquoi lire tel champs , le formater de telle façon, etc ...)

On dirait qu'il y a autant de structures MVC qu'il y a de jours dans l'année

C'est pas tout à fait ça , mais pas loin.
n gros le MVC est un principe et chacun l'applique un peu comme il le souhaite. Si tu choisi d'avoir un controller par page plutôt que par fonctionnalité , c'est ton choix. C'est pas moins valable. L'important étant que les couches M,V,C soient clairement séparées.
Idem pour l'organisation au niveau des dossiers , chacun fait comme il l'entend

[Reelo]

Ouai ben tout ça pour dire que c'est pas évident du tout. ça promet de belles séances de triturage neuronales .
Avec ma configuration donnée plus haut,voilà comment je fais.Le routeur reçoit les données de l'url en fonction d'une action réalisée, et vérifie que les paramètres qui y sont transmis sont valables (quand je dis valables je veut dire que les variables ne sont pas vides et que l'action correspond à quelque chose d'attendu ). Ensuite il les envoie à un contrôleur lequel appelle un manager (modele) qui les vérifie et récupère les données dans la bdd . le manager reconstitue les objets correspondants aux classes métiers et renvoie le tout au contrôleur lequel génère la vue de la page demandée. Et ça , pour chaque page. c'est un peu court comme résumé mais en gros c'est ça. En revanche mon routeur a tendance à l’embonpoint et augmente en taille à vitesse grand V. il va falloir voir ça . j'espère qu' avec la pratique pouvoir optimiser l'architecture du code et le rende un peu moins lourd.

[CinePhil]

En revanche mon routeur a tendance à l’embonpoint et augmente en taille à vitesse grand V.

Selon moi, le boulot du routeur est juste de vérifier que l'action demandée par l'utilisateur est prévue par le programme puis d'appeler le contrôleur adéquat qui va effectuer l'action demandée.
Une fois ça programmé, il n'y a plus de raison qu'il grossisse. À lire ton message, j'ai l'impression que tu lui fais faire des tâches de vérification qui relèvent plutôt du boulot du contrôleur.

[grunk]

Cinéphil à absolument raison. Ton routeur ne doit pas grossir. Il est écrit une fois et on y touche plus jamais quelque soit le nombre de controller.

Ton routeur lit l'url, en extrait le controller et éventullement l'action du controller à déclencher. Il peut aussi éventuellement extraire les données de l'url , même si je suis pas 100% convaincu que ce soit son job.

En simplifiant dans mon routeur il se passe ceci :

Code :

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

1
2
3
4
$class = $this->ns.'\\'.$this->controller.'Controller';
$controller = new $class($this->request);
$action = $this->action;
$controller->$action(); // Par exemple appel IndexController#liste();

[Reelo]

bonsoir
Si j'ai bien compris le code (quoique je n'en suis pas sûr) dans le lien 'mon routeur' de grunk, c'est le code d'un routeur générique qui appelle un contrôleur en fonction de l'action ? si c'est ça, j'en suis encore loin.
Pour le moment à mon modeste niveau je n'ai rien de configurable et ce n'est pas aussi sophistiqué. Le routage des requêtes est fait manuellement par le routeur . Ceci explique peut être pourquoi mon routeur est si volumineux .
je suis obligé de tous mettre à chaque fois dans des conditions pour choisir l'action à mener. Donc au niveau optimisation c'est nul. Mais bon, pour le moment ça fonctionne et ça me permet de voir le cheminement à effectuer pour coordonné tout ça. Pour répondre à CinePhil, mon routeur ne fait que récupérer l'action demandée et mettre toutes les variables issues de $_GET ou $_POST dans des variables plus simples rien de plus. Le routeur appelle le contrôleur avec les nouvelles variables comme par exemple pour entrer des produits en stocks:

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
20
21
22
23
24
25
26
 
class Routeur
{
 
...code
 
elseif($_GET['action'] == 'entreeStocks') //entrée en stock de produits
{
	if(!empty($_POST))
	{
		$nomMarque = $this->getParametre($_POST, 'choixMarque');
		$this->ctrlEntreeStocks->entreeStocks($nomMarque);
	}
}
elseif($_GET['action'] == 'sortieStocks') //sortie des stocks de produits
{
	if(!empty($_POST))
	{
		$nomMarque = $this->getParametre($_POST, 'choixMarque');
		$this->ctrlSortieStocks->sortieStocks($nomMarque);
	}	
}
 
...code
 
}

Le problème est que je suis vite limité et ça reste répétitif et basique au niveau modularité j'en suis bien conscient. Donc après je vais essayé de simplifier et modifier tout ça.

[grunk]

bonsoir
Si j'ai bien compris le code (quoique je n'en suis pas sûr) dans le lien 'mon routeur' de grunk, c'est le code d'un routeur générique qui appelle un contrôleur en fonction de l'action ? si c'est ça, j'en suis encore loin.

C'est bien ça. Le router est générique dans le sens où il est capable de charger n'importe quel controller existant en fonction de l"url et d'en charger un particulier en cas d'erreur (controller innexistant par exemple).
C'est peut être effectivement un peu avancé par rapport a ce que tu sais faire pour le moment , mais tu finiras par y arriver

[Reelo]

Bon, et bien le chemin est encore long et parsemé d'embûches. y' a du boulot en perspective.
En tous cas merci beaucoup pour vos réponses.