Aller au contenu

S'initier au Zend Framework/Concepts

Un livre de Wikilivres.
Zend Framework
Programmation PHP / Zend Framework
Programmation PHP / Zend Framework
Sommaire
Modifier ce modèle


Le patron de conception Modèle vue contrôleur (MVC)

[modifier | modifier le wikicode]

Zend Framework comme tous les cadriciels majeurs des langages de scripts serveurs utilise le patron de conception Modèle-vue-contrôleur qui sépare le modèle de données, l'interface utilisateur et les traitements. Ces trois parties fondamentales se nomment : le modèle, la vue et le contrôleur[1].

Le modèle ne s'occupe que du traitement des données, les liens avec la base de données, lecture, insertion, mise-à-jour des tuples dans une base, vérifier que les données sont bien formatées (validation). La présentation des résultats ne se fait pas dans le modèle.

La vue correspond à la présentation des résultats, par exemple un tableau HTML, PDF pour un utilisateur ou sous forme XML pour fournir un programme distant. Les évènements et les actions de l'utilisateur (clic d'un bouton, liste de sélection, etc) sont gérés dans la vue. Cette séparation permet au graphiste de travailler sans avoir à se soucier des rouages de l'application.

Le contrôleur prend en charge le déroulement du programme. La liste des actions sera dans le contrôleur. Il synchronise les événements provenant de l'utilisateur vers la base de données.

Ce patron de conception existe traditionnellement dans les langages objet comme Java comme par exemple la bibliothèque graphique SWING et est employé généralement dans les langages web comme la plateforme Adobe/Flex ou la prochaine norme W3C de formulaires Xforms. Cette orientation a été perçue très tôt par les développeurs web notamment avec la popularité du framework Ruby on Rails. L'éditeur de PHP, Zend a pris la même orientation tout en conservant les développeurs ne souhaitant pas migrer vers MVC et permet ainsi d'utiliser ZF comme une bibliothèque classique.

Avantages et inconvénients de l'architecture MVC.

[modifier | modifier le wikicode]

« Given enough eyeballs, all bugs are shallow » (pour assez de globes oculaires, tous les bugs sont superficiels) - Linus Torvalds.

L'avantage premier est la modularité, les objets sont réutilisables dans une autre application. Le cloisonnement ajoute en facilité de maintenance. De plus, la modification des traitements se fait indépendamment de l'affichage (la vue). Il faut préciser que les développeurs qui sont impliqués dans l'amélioration du framework proposent des composants issus de la théorie informatique (comme les design patterns) ou le fruit de l'expérience par de bonnes pratiques de programmation.

L'inconvénient est une phase de conception plus longue et ces ajouts de couches multiplient le nombre de fichiers sur le serveur. Cela nécessite des outils spécifiques de débogage et de mécanismes d'amélioration des performances (cache). Le temps d'apprentissage est à prendre en compte pour les développeurs.

Zend Framework : Fonctionnement

[modifier | modifier le wikicode]

L'apprentissage du fonctionnement du framework peut être un peu ardu, car cela nécessite une connaissance de quelques concepts de programmation orientée objet. Mais la consultation de la documentation, du tracker de bugs, des blogs des développeurs permettent d'en comprendre la globalité.

Le processus d'une requête est :

  1. Le bootstrap (html/index.php) est le point d'entrée dans l'application, il s'agit de l'implémentation du design pattern contrôleur frontal[2] et d'un singleton. Toutes les requêtes passent par cet objet, à sa charge d'acheminer (dispatcher) vers les actions (suivant une route par défaut ou définie par le concepteur). Les réponses sont collectées par cet objet.
  2. La requête peut d'abord être pré-traitée dans un plugin, cela permet au concepteur d'effectuer des traitements en tout début de requête.
  3. La requête est routée, c'est à dire que l'on traduit l'URI d'entrée en lien vers le bon contrôleur. Le contrôleur est instancié, son constructeur init() est lancé.
  4. La fonction preDispatch() est lancée si elle existe juste avant de lancer l'action : par exemple readAction(...).
  5. Le contrôleur se termine et la fonction postDispatch() est lancée.
  6. La réponse est renvoyée au visiteur.
  1. Model-View-Controller (MVC), Trygve M. H. Reenskaug - http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
  2. A controller that handles all requests for a Web site., Martin Fowler, http://www.martinfowler.com/eaaCatalog/frontController.html