Motif Modele Vue Controleur et PHP

Le motif de conception MVC est très utilisé dans la construction d’applications web. Ce principe nous permet de construire des applications 3-tiers et permet également une séparation utile du code en plusieurs couches. Il aide aussi pour une meilleure collaboration entre les designers et les développeurs et améliore les capacités de ces derniers à maintenir et développer les applications existantes.

 LA VUE

Les “Vues” correspondent généralement au résultat final envoyé vers un navigateur - le code HTML généré par notre script par exemple. En parlant des vues, beaucoup de gens pensent aux moteurs de “templates”, mais on peut débattre sur le fait d’appeler un moteur de template une “vue”.

Peut-être que le point important sur les Vues est qu’elles doivent “connaître” quand une vue est rendue le rôle de chaque élément dans le contexte global. Si on prend l’ XML comme exemple, on pourrait dire que l’ XML analysé par l’API Document Object Model à cette connaissance - un nœud dans un arbre DOM connait sa position dans l’arbre et ce qu’il contient alors que les nœuds d’un document XML analysé par SAX n’ont aucune connaissance sur eux-mêmes jusqu’à ce que l’analyseur les atteigne.

La plupart des solutions de template utilisent un certain langage plutôt simplifié et des balises de template ressemblant à ceci :

Elles n’ont aucune connaissance du document qui va être créé ou ce qu’elles représentent et sont simplement là pour que PHP les remplace par quelque chose d’autre.

Si vous êtes d’accord avec cette description d’une Vue, vous serez également d’accord sur le fait que la plupart des moteurs de templates échouent dans la division désirée du Modèle et de la Vue, la connaissance du résultat de la transformation des balises étant conservée dans le Modèle.

Des questions que vous devez vous poser quand vous créez vos Vues : « Est-il facile de faire des changements globaux pour toutes les vues ? », « Peut-on échanger facilement le langage de présentation délivré par la Vue avec un autre (par ex. délivrer un document SOAP [1] au lieu d’un document HTML à partir de la même Vue) ? »

 LE MODÈLE

Le Modèle représente la logique de l’application (souvent appelée la “Couche Métier” dans les Application de classe Entreprise).

En résumé, le « boulot » du Modèle est de transformer les données brutes en données qui ont une signification pour l’application et qui sont délivrées à la Vue pour affichage. Le Modèle encapsule souvent les requêtes à la base de données, pouvant éventuellement tirer parti d’une classe d’abstraction de base de données (une couche d’accès aux données) pour exécuter les requêtes.

Par exemple, vous voulez calculer les précipitations annuelles au Royaume-Uni (juste pour vous convaincre qu’il y a de meilleurs destinations pour passer ses vacances !), le Modèle recevrait les chiffres des précipitations journalières sur dix ans, calculerait la moyenne et délivrerait le Résultat à la Vue.

 LE CONTRÔLEUR

Le controleur est d’abord le premier point d’entrée pour toutes les requêtes HTTP reçues dans une application Web. Il examine ce qu’il a reçu dans la requête, comme une collection de variables GET, et répond de façon appropriée. En fait, vous pouvez difficilement commencer à coder en PHP sans écrire votre premier contrôleur quelque soit la forme que vous lui donnez. La forme la plus courante et la plus simple peut être une instruction switch() dans votre fichier index.php qui pourrait ressembler à ceci :

Cet exemple mixe du code procédural et orienté objet, mais pour un petit site web, c’est souvent un choix parfaitement valide. Ce code pourrait bien entendu être amélioré.

Le rôle essentiel du Contrôleur est de déclencher la liaison entre les données provenant du Modèle aux éléments de la Vue.

 UN EXEMPLE

Voici un exemple du motif MVC en action.

Premièrement nous avons besoin d’une couche d’accès aux données, qui est une classe générique :

DataAccess.php

Au dessus on place le Modèle :

ProductModel.php

Une chose importante à noter : le Modèle et la classe d’accès aux données n’échangent jamais plus d’un seul enregistrement à la fois, sous forme de tableau - on ne passe pas tous les enregistrements retournés par la requête d’un seul coup, ce qui pourrait sérieusement ralentir une application. Le même principe s’applique à la classe qui utilise le modèle - elle a seulement besoin de conserver une seule ligne en mémoire à la fois - le reste est laissé à la charge de la ressource de la requête - en d’autres termes, on laisse à MySql le soin de nous conserver le résultat.

Ensuite la Vue. J’ai supprimé le code qui produit du HTML pour réduire la taille de l’article mais vous le retrouverez dans le code complet pour cet article.

ProductView.php

Et enfin le Contrôleur que nous implémenterons comme “fils” de la Vue :

ProductControler.php

Notez que ce qui est présenté ici n’est pas la seule façon de relier les classes dans un motif MVC - on pourrait changer pour un Contrôleur qui implémente le Modèle tout en agrégeant la Vue. Il s’agit juste d’une approche qui présente le motif.

Notre fichier index.php :

Net et simple.

Il est important de noter que nous aurions pu être plus astucieux pour le contrôleur. En PHP vous pouvez utiliser ce genre de truc :

Cette approche suggère que vous définissiez pour vos applications un espace de noms pour les URL pour qu’elles se conforment à un standard comme celui-ci :

En utilisant cette technique on pourrait utiliser le code suivant dans notre contrôleur :

D’une certaine façon, la construction du contrôleur est le point le plus difficile lorsqu’il s’agit de trouver le bon équilibre entre rapidité de développement et capacité à monter en charge. Un bon emplacement pour trouver de l’inspiration est Java Struts du groupe Apache où votre contrôleur est essentiellement définit par des documents XML.

COMMENTAIRES

J’ai eu deux ou trois commentaires sur cet article …

Votre classe ProductController est héritée de la classe ProductView. Ce faisant, on n’obtient pas une séparation du contrôleur et de la vue, puisque le contrôleur ’Est’ la vue (à cause de la relation d’héritage). Vos classes View et Controller devraient être complètement séparées et le contrôleur devrait renvoyer une Vue comme dans cet exemple :

2) Dans le motif de conception MVC, une vue n’a toujours qu’un contrôleur et un seul. Dans votre code exemple, vous utilisez un contrôleur pour en fait deux vues : productItem et productTable. Vous devriez utiliser deux contrôleurs séparés pour ces deux vues.

3) Le but d’un Contrôleur dans une application de bureau MVC est de réagir aux actions de l’utilisateur comme taper du texte, cliquer sur la souris etc… Comme PHP est un langage côté serveur il n’a pas besoin de contrôler ces choses. A mon avis, le seul objet d’un contrôleur en PHP serait pour les vues qui utilisent un formulaire dont le but est d’afficher et d’éditer des informations venant du Modèle. Le contrôleur « réagit à cette saisie » en appelant les méthodes appropriées du Modèle (par exemple $obj->saveToDatabase()). Dans votre exemple, c’est le contrôleur qui décide quelle vue aficher.

4) Une autre tâche du Contrôleur est de charger les objets du Modèle. Dans votre exemple, vous passez l’objet du modèle au contrôleur comme paramètre. Comme un contrôleur ne peut seulement être utilisé qu’avec un seul type de Modèle, le passer en paramètre au Contrôleur n’a pas de sens.

Je comprend qu’il est difficile voire impossible d’appliquer directement le motif MVC tel qu’il a été conçu pour les applications de bureau, à cause du mode de fonctionnement même du web et de PHP (mode déconnecté ou asynchrone). Il faut donc modifier un peu le motif pour un langage comme PHP. Mais si vous voulez coller au plus près au motif MVC original, votre fàçon de le faire n’est certainement pas la bonne. Vous êtes sur la bonne voie, mais je vous conseille de faire plus de recherches sur MVC et ensuite retourner à votre clavier

Pas de problème Et un grand merci pour votre commentaire. J’espère mettre en ligne une nouvelle version de cet article dans la semaine qui vient.

Au delà de çà, il semble qu’en fait je mélange le motif « Contrôleur Principal » (’Front Controller’) avec le « Contrôleur ».

Je vais essayer de mettre en place quelque chose pour réviser le motif MVC que j’ai présenté et incorporer en même temps l’idée de Contrôleur Principal.