»
le MVC dans le contexte web
La logique applicative (modèle) est constituée des scripts réalisant les demandes de l'utilisateur, des classes métiers et des classes d'accès aux donnéesL'interface utilisateur (vue) sera géré la plupart du temps par un navigateur web, elle peut éventuellement être un autre site web communiquant via des webservices. Dans les deux cas tout va se passer via HTTP.
La source de données sera une base de données dans toute la suite mais pourrait parfaitment être un serveur LDAP, un webservice, des fichiers texter ou encore XML.
le MVC est bien adaptée à des applications web écrites avec des langages orientés objet, nous allons essayer de tirer le meilleur parti des nouveautés de PHP5.
diagramme générique d'une application web/php MVC
- couche ihm: c'est l'interface utilisateur encore appelé interface homme machine
- couche métier : c'est le coeur de l'application où réside les objets tréités par l'application
- couche dao : couche d'accès aux données (data access object). Cette couche permet une indépendance de la logique métier et du stockage des données associées
- le client fait une demande au controleur. Ce contrôleur voit passer toutes les demandes des clients
- le contrôleur traite la demande. Pour ce faire, il peut avoir besoin de l'aide de la couche métier, et éventuellement de la couche dao.
- le contrôleur reçoit une réponse de la couche métier et effectue les actions demandées par l'utilisateur
- le controleur sélectionne et nourrit une vue pour présenter les résultats de l'action qui vient d'être effectuée
- la vue est enfin envoyée au client
Proposition d'architecture
Interaction utilisateur
Il est raisonnable de raisonner par action. Une action sera vue comme une partie inséquable du code du contrôleur.l'interaction utilisateur se fait via les variables http soit par des variables associées à l'url en methode GET ou par des variables de formulaires en méthodes GET ou POST.
Ces variables devront donc contenir en premier lieu l'action que le controleur a à effectuer (nous appellerons cette variable '$action').
Le controleur
Le controleur devra donc commencer par analyser la requête http afin d'en extraire l'action réaliser. D'autres variables pourront être passées pour les besoin d'un traitement.Une fois l'action l'ocalisée elle sera exécutée. Une vue devra lui être affectée
le début du controleur ressemblera donc à ça
if($_GET['action']) // appel d'une action via la méthode http GET
{
$action = $_GET['action'];
}
elseif($_POST['action']) // appel d'une action via la méthode http POST
{
$action = $_POST['action'];
}
else // acune action n'est appelée on affiche la page d'accueil
{
$action='index';
}
if(is_callable($action)) // on vérifie que l'action est bien définie dans le controleur
{
call_user_func($action);
}
else
{
call_user_func('404');
}
les actions index et 404 doivent être définies quoiqu'il arrive.
chargement des classes
A priori une action va faire appel à un ou plusieurs objets. Il est donc indispensable que les bonnes classes soient chargées lors de l'exécution d'une action. Le principe de chargement automatique des classes mis à disposition par PHP5 paraît tout indiqué. Le tout est de s'accorder sur une logique de stockage des classes métiers. Si toutes les classes sont stockées dans un répertoire nommé obj à la racine du site dans des fichiers nommés selon la convention suivante nom_de_classe.class.php la fonction de chargement automtqieu ressemblerait alors à quelque chose comme ça:function __autoload( $nom_de_classe )
{
require_once('obj/'.$nom_de_classe.'.class.php');
}
sélection de la vue
Il est intéressant de bien distinguer les parties statiques des parties dynamiques. La parties statiques seront icluses systématiquement par le controleur, alors que les les vues affectées aux parties dynamiques seront sélectionnées foncions de l'action demandées par l'utilisateur. La encore tout est question d'organisation.Les fichiers core
Afin de factoriser au maximum le code à écrire nous regrouperons tout le code générique dans un dossier (que nous appellerons 'mvc'). ce dossier sera le coeur de notre application.Les modèles
la couche dao
La plupart du temps les données seront stockées dans une bases de données. Une bonne idée pour rendre la couche dao indépendante du stockage est de passer par une couche d'abstraction base de données (PDO, PEAR::MDB2, creole, ...). Il est à noter que souvent les objets métiers vont avoir des méthodes communes d'accès et de manipulation des données: typiquement les méthodes CRUD (Create Read Update Delete) risquent d'être communes à tout objets stockés en base de données.Une autre approche tentante est de déduire la plus grande partie du modèle en analysant la description du stockage des données. Dans le cas d'une base de données par exemple, on peut associer un objet à une table, et en listant les champs de cette table en déduire dynamiquement les attributs de l'objet. Ce processus porte le nom de couche ORM (Object Relational Mapping) (propel, doctrine, ...).
