Le Modèle-Vue-Contrôleur (en abrégé MVC, de l`anglais Model

Transcription

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l`anglais Model
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est
une architecture et une méthode de conception qui organise la conception d’un site web.
Cette organisation divise le travail (programmation) en un modèle (modèle de données,
script de référence), une vue (présentation, interface utilisateur, HTML) et un contrôleur
(logique de contrôle, programmation central, validation).
Imposer la séparation de notre code suivant un modèle standard permet aux
programmeurs de se retrouver facilement dans le code et d’imposer un standard dans la
nomenclature et le style de programmation. Ceci permet entre autre d’éviter de chercher
plusieurs heures dans un code programmer par un autre employé.
Cette architecture est utilisée dans Flex, Symfony, CakePHP, CodeIgniter, Zend, etc.
Le modèle représente le comportement de l'application : traitements des données,
interactions avec la base de données, etc. Il assure la gestion de ces données et
garantit leur intégrité. Dans le cas typique d'une base de données, c'est le modèle qui la
contient. Le modèle offre des méthodes pour mettre à jour ces données (insertion,
suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ces
données. Les résultats renvoyés par le modèle sont dénués de toute présentation.
Les modèles sont encore peut exploiter dans nos projets, notamment à cause de la
simplicité de ceux-ci. Le développement des modèles exige également plus de temps de
développement à notre stade mais permet d’accélérer la manipulation d’une table dans
une base de données. Ceci peut être très utile s’il est possible de gérer le même
élément à plusieurs endroits. Nous plaçons également dans le modèle des scripts
génériques (nettoyeur de nom de fichier, calculateur, etc) qui peuvent être appelé par
les contrôleurs pour simplifier le code.
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est
de présenter les résultats renvoyés par le contrôleur. Sa seconde tâche est de recevoir
toutes les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons…). Ces
différents événements sont envoyés au contrôleur. La vue n'effectue aucun traitement,
elle se contente d'afficher les résultats des traitements. Bref, c’est généralement du
contenu HTML.
Le contrôleur prend en charge la gestion des événements de synchronisation pour
mettre à jour la vue et la base de données. Il reçoit tous les événements de l'utilisateur
et enclenche les actions à effectuer. Si une action nécessite un changement des
données, le contrôleur demande la modification des données au modèle ou dans notre
cas, fait directement la modification des données et ensuite avertit la vue que les
données ont changé pour qu'elle se mette à jour. C’est dans les contrôleurs que la
grande partie du développement d’un site web se trouve.
Un projet web est initialement divisé en trois grands dossiers. Le dossier application
contient le modèle MVC et donc, toute la programmation fait par nous. Le dossier
library contient toutes les classes de programmation de Zend, le cœur de Zend. Il peut
inclure d’autres classes de programmation comme celle de Facebook et de CakeMail.
Le dossier public comprends tous les éléments qui vont être accessible publiquement et
consulter par l’utilisateur (images, css). Le serveur pointe donc directement sur ce
dossier qui comprend index.php. Le but du fichier index.php est de renvoyer le serveur
dans le dossier application en connectant les classes dans le dossier library.
Voici l’architecture presque de base :
application/
controllers/
IndexController.php
NewsController.php
models/
DbTable/
News.php
views/
scripts/
index/
index.phtml
news/
index.phtml
helpers/
filters/
config/
application.ini
layouts/
scripts/
layout.phtml
bootstrap.php
library/
Zend/
public/
.htaccess
index.php
images/
css/
js/
L’un des avantages de cette structure est au niveau de la sécurité. En effet, comme
l’adresse du site web pointe directement dans le dossier public, il est impossible de
revenir en arrière dans l’url avec les deux points « ../application/ ». Les fichiers sont
donc utilisé et visible exclusivement par le serveur.
On remarque la présence du fichier bootstrap.php dans le dossier application. Le
bootstrap permet de faire des configurations de base et d’initialiser les modules qui
seront appelé.
Un contrôleur est une classe qui peut contenir plusieurs actions permettant de contrôler
plusieurs pages. On créé généralement un contrôleur pour un module. Par exemple,
pour un module permettant la gestion de la nouvelles, on pourrait avoir un contrôleur
NewsController permettant de faire les actions d’ajouter, de modifier, de supprimer et de
consulter. Ainsi, notre contrôleur pourra contenir les fonctions AddAction, EditAction,
DeleteAction, ManageAction.
Le nom des fonctions réalisant les actions doivent terminer par "Action"; et le nom des
contrôleurs par « Controller ». Ainsi, ces méthodes peuvent alors être demandées via le
web. Par défaut, l’url des projets Zend respectent le schéma « controller/action, où
"controller" pour le nom du contrôleur d'action (moins le suffixe "Controller") et «action»
pour une méthode d'action (moins le suffixe "Action"). Ainsi, pour aller ajouter une
nouvelle, l’adresse du site web serait ceci : www.domaine.com/news/addnews .
Typiquement, il devrait toujours y avoir un IndexController et un ErrorController. Le
IndexController permet de généré la page d’accueil du site et le ErrorController de
générer les erreurs rencontrés soit dans la programmation ou d’autres types comme une
erreur http 404 (contrôleur ou l'action introuvable) ou http 500 (erreurs d'application).
Voici un contrôleur de base :
// application/controllers/IndexController.php
class IndexController extends Zend_Controller_Action
{
public function init()
{
/* Initialize action controller here */
}
public function indexAction()
{
// action body
}
}
Les scripts de vue sont écrits en html pouvant contenir du php (.phtml). Ils sont placés
dans le dossier « application/views/scripts/ » où ils sont encore subdivisés en utilisant
les noms de contrôleurs. Dans notre cas, nous avons un IndexController et un
NewsController. Il y a donc deux dossiers dans le dossier scripts (index et news). Au
sein de ces sous-répertoires, vous pourrez ensuite trouver et de créer des scripts de vue
qui correspondent à chaque action du contrôleur exposés, dans le cas par défaut, nous
avons donc les scripts de vue index.phtml
Exemple de vue index.phtml :
<!-- application/views/scripts/index/index.phtml -->
<div id="welcome">
<h1>Welcome to the <span id="zf-name">Zend Framework!</span><h1 />
<h3>This is your project's main page<h3 />
<div id="more-information">
<p>
<img
src="http://framework.zend.com/images/PoweredBy_ZF_4LightBG.png" />
</p>
<p>
Helpful Links: <br />
<a href="http://framework.zend.com/">Zend Framework
Website</a> |
<a href="http://framework.zend.com/manual/en/">Zend
Framework Manual</a>
</p>
</div>
</div>
Le modèle est encore peu exploiter dans nos projets Zend parce que nous avons
réussis à adapter facilement nos contrôleurs pour effectuer les tâches demandé avec la
base de données. La connexion avec la base de donnés avec fait dans le fichier
application.ini dans le dossier configs. Le fichier est simple et contient les informations
de connexions. Nous sauterons par-dessus les explications de ce fichier, l’important est
de s’assurer que les informations sont bonnes pour que le site soit bien connecté.
Pour l’instant, ce que nous faisons avec les modèles, c’est la création de classe qui va
servir d’instance pour manipuler les tables d’une base de donnés.
Exemple d’instance à la table News :
<?php
// application/models/DbTable/News.php
/**
* C’est une classe DbTalbe pour la table news.
*/
class Default_Model_DbTable_News extends Zend_Db_Table_Abstract
{
/** Table name */
protected $_name
= 'news';
}
Pour exploiter encore mieux ces classes, c’est là que nous pourrions mettre nos
fonctions AddNews, EditNews, DeleteNews. Pour l’instant, c’est directement dans nos
contrôleurs que ces actions sont effectuées.

Documents pareils