Revenir
en haut

Le MVC dans Symfony 2: cheminement d’une requête HTTP

25/02/2011 3

L’activité autour de Symfony 2 est très importante depuis quelques mois. Certaines décisions concernant l’architecture du framework et de ses composants devaient être prises avant la phase de stabilisation pour éviter de traîner des casseroles dans les belles années à venir pour l’outil.

Heureusement, je pense pouvoir dire sans trop me tromper que le framework est entré dans une véritable phase de stabilisation et que la core team et les contributeurs travaillent d’arrache pied pour l’arrivée du Symfony Live 2011 à Paris.

Ce qui me permet de démarrer une série d’articles sur Symfony 2, dont la première partie concernera le MVC tel qu’il est introduit dans le framework.

Introduction

Une introduction logique pour analyser l’implémentation du MVC et de suivre le parcours d’une requête HTTP.

Un gros travail de documentation sur le framework est en cours et je vous invite vivement à lire les différents guides, regroupés maintenant dans une section intitulée « Book », et deviennent donc des chapitres, qui plus qu’une simple documentation de référence, expliquent de façon simple et accessible (si vous maîtrisez l’anglais bien entendu) les différents concepts derrière la philosophie et les composants et/ou bundles de Symfony 2. Il y a une continuité dans les sujets, c’est très appréciable pour de la doc. :)

Concernant notre requête HTTP, si ce n’est pas déjà fait, je vous recommande avant de continuer, de lire ce chapitre : The HTTP Spec and Symfony2 Fundamentals, qui est d’ailleurs le premier chapitre, c’est bien, jusque là nous restons logiques !

Cheminement d’une requête HTTP : diagramme

Le chapitre pré-cité étant très bien écrit, je n’ai rien à y ajouter, d’autant plus que ça ne serait pas mieux raconté que part un développeur concerné.

Je vous propose par contre de découvrir le cheminement d’une requête HTTP dans Symfony 2 sous forme de diagramme, plus ou moins un Workflow. Sachant que je n’ai pas respecté de règles particulières pour faire cette représentation, et que je ne peux malheureusement pas tout détailler. Mais si vous êtes comme moi, et que vous aimez avoir un schéma sous la main, servez-vous.

Symfony 2 - Cheminement d'une requête HTTP

Un framework « agnostic »

Pour apporter un peu de précisions sur le diagramme, j’attire votre attention sur la forme agnostic du coeur du framework. Une implémentation du MVC est proposée, mais vous constatez qu’elle est totalement indépendante de la gestion de la requête HTTP, et pourrait être très facilement remplacée.

Comme l’explique très bien la documentation, le coeur du framework propose simplement une série d’objets permettant de manipuler facilement une requête et une réponse HTTP (HttpFoundation).

Autour de ces composants, les opérations sont orchestrées par le gestionnaire d’événements (Event Dispatcher), qui va notifier à ceux qui écoutent ces événements (listeners) que c’est le moment d’intervenir. Ils vont donc altérer tour à tour l’objet de réponse (Response).

Grâce au conteneur de dépendances, il apparait très clairement que nous pouvons détacher n’importe qu’elle partie, pour la remplacer par une autre. D’ailleurs à ce sujet, vous constatez que je met en avant des implémentations concrètes de certaines briques, notamment le routage et la résolution du contrôleur et de ses paramètres. Sachez que le coeur du framework ne propose la plupart du temps que des interfaces, voir des implémentations très génériques, et que les implémentations ne font pas partie des composants du core, mais sont dans le bundle FrameworkBundle. Je cite celles-ci car c’est le fonctionnement par défaut, et celui que la plupart d’entre vous devrait adopter.

Mais il serait donc très simple de ne conserver que le coeur du système, et de créer votre propre framework MVC. Pour ça, il « suffit » d’implémenter les différentes interfaces (contrats), et de connecter des listeners sur les différents événements clés.

Note : il serait également possible de remplacer le HttpKernel par votre propre version, à condition de respecter certaines règles, même si, comme ça, je ne vois aucun intérêt particulier à faire ça.

Evénement core.view

Certains se poseront peut-être la question de l’utilité de l’événement « core.view », qui est dispatché si un contrôleur n’a pas retourné d’objet de type HttpFoundation\Response.

Dans Symfony 2, la création de l’objet de réponse est explicite, c’est au contrôleur de le créer, de le nourrir avec ce qu’il veut, par exemple le résultat du rendu d’une vue/template, et de le retourner.

J’espère ne pas me tromper en disant ça, mais certains contributeurs se sont plains de ne pas avoir une véritable couche « Vue », et j’oserais croire que cet événement permettrait à qui veut, de créer sa propre couche présentation, du moment qu’un objet réponse est fournit en retour. Si quelqu’un veut préciser ce point, il est le bienvenu :)

Addendum

Je précise que ce diagramme n’est pas du tout officiel, et que je ne suis pas à l’abri d’une erreur. C’est une première version, je ne doute pas qu’elle sera améliorée. Tous vos retours seront très appréciés.

J’ai décidé volontairement de détailler certaines parties du Worflow et d’autres non, pour ces dernières, il faudra fouiller le code :)

3 commentaires :

  1. Amo__ :

    Merci pour cette vue d’ensemble ;-)

    note : dans ton premier paragraphe de la section « Un framework agnostic » tu a écris

    et pourrez être très facilement remplacée.

    au lieu de

    et pourrait être très facilement remplacée.
  2. Pingback: Symfony2 | Pearltrees

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

Tags HTML autorisés : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Tag code : [cc lang="langage"][/cc] (ex. [cc lang="php"][/cc])