drupal synology
Drupal Passer de la v7.34 à la v7.37 sur Synology
22/06/2015
Carton Rouge
#CartonRouge décerné à François Rebsamen
25/06/2015

Le modèle MVC-2

Le MVC-2 est un dérivé de l’approche MVC (modèle – vue – contrôleur) basique. Il consiste à n’utiliser qu’une Servlet comme aiguilleur global sans jamais lui déléguer l’exécution du code “Métier” (le “M” de MVC, “M” comme “modèle”).

Le traitement des requêtes en provenance des pages Web (les “Vues” du modèle MVC) est “délégué” à de simples Pojo’s implémentant une interface qui définit une méthode acheminant les arguments Request et Response.

Présentation globale de MVC et MVC-2

La première fois qu’on code un contrôleur, le “C” du MVC, on obtient un fichier immense et illisible, au mieux peu lisible.

D’autre part, le fait de concentrer l’ensemble des actions d’aiguillage au sein d’un même fichier rend difficile le travail en équipe puisque chacun devrait pouvoir intervenir simultanément sur le contrôleur afin d’y paramétrer le traitement des actions découlant des requêtes générées par les différentes pages.

Modèle MVC

C’est tout l’intérêt de cette approche MVC-2 que de sous-traiter ces opérations à des POJOs, le contrôleur n’ayant plus comme unique job que d’aiguiller la requête – et donc son traitement – vers le bon POJO, s’appuyant pour ce faire sur les infos contenues dans le fichier de configuration web.xml.

Modèle MVC-2

Fonctionnement du MVC-2

Grâce à l’interface qu’ils implémentent, les POJOs simulent le comportement de la servlet qui leur a délégué le traitement du flux en provenance des pages.

Pour aiguiller correctement les flux vers les POJOs, le contrôleur s’appuie sur le fichier de configuration WEB.XML

Les requêtes en provenance des pages (dans le cas de Java, les JSP) contiennent les ordres à exécuter par la Servlet. Elles sont formatées selon un modèle du type :

action=servlet?section=bloc_de_la_servlet_à_exécuter&parameter1=xxx&parameter2=yyy&parameterN=zzz”

Dans le MVC-1, la servlet devait tout gérer.

Son code était donc composé de différents blocs d’instructions en charge des différentes “sections” appelées par nos pages. A l’intérieur de ces blocs, on pouvait éventuellement trouver des “sous-blocs”, etc. Il était nécessaire de déterminer la chaine de caractères contenue dans la QueryString à droite du “section=…” pour exécuter le bon bloc de code.

String section = request.getParameter(“section”);

if(section.equals(“ma_section”) { code à exécuter }

Les paramètres – “parameterN” – étaient quant à eux transmis aux Java Beans via un appel de la servlet.

Dans le MVC-2, au contraire, la servlet n’est pas divisée en “sections” en charge du traitement des “requests”. La servlet ne contient qu’un section, celle en charge de “mapper” les sections indiquées dans les requests et les POJOs qui simulent la servlet (ou controler).

Pour que cela fonctionne, il est nécessaire de renseigner le fichier de configuration WEB.XML de la façon suivante :

WEB.XML

Parameter Name Parameter Value
versSectionAccueil fr.mon_site.mon_package.pojoAccueil
versSectionLogin fr.mon_site.mon_package.pojoLogin
etc.

A la lecture de la valeur contenue dans la chaine de caractère “section=…”, par exemple “section=versSectionLogin”, la servlet réoriente la requête vers la pseudo-servlet “pojoAccueil”, en charge de l’exécution du code “métier”.

De son côté, le POJO est en mesure de traiter les paramètres de la requête, de faire appel aux Java Beans puis, une fois qu’il a terminé, de renvoyer une URL au controler (la servlet) qui fera alors appel à la page.

Pour ceux d’entre vous qui ont une expérience dans ce domaine, on serait heureux d’avoir vos impressions et avis sur cette approche. Des alternatives peut-être ?

Fred

Commenter directement depuis Facebook

Nous apprécions vos commentaires.

avatar
WordPress spam bloqué par CleanTalk.
  Subscribe  
Notify of

Coup de pouce

Merci d'avance de partager ce post sur votre réseau social favori.

Le modèle MVC-2

Présentation du modèle MVC-2 et de ses avantages par rapport au MVC de base.
Skip to toolbar