Architectures NTiers Paradigme MVC

1. Architectures NTiersParadigme MVC francois.pfister@mines-ales.fr 2012-2013

2. Architecture 4Tiers – MVC2 simplifié serveur web (tiers 2) Client (tiers 1) serveur données (tiers 4) Serveur métier (tiers 3) Contrôleur CustomerServlet CustomerDao BankServlet BankDao AccountServlet AccountDao Customer.java 1 persistance 2 Bank.java Stocké à long terme Customer.jsp 3 Account.java session Bank.jsp 4 Stocké temporairement 5 Account.jsp Modèle 6 Vue 7 8 NB: les séquences 2,4,7 et 8 schématisées comme des relations 1-1 peuvent être croisées 9

3. Cycle requête-réponse nominal 1 Une requête http est émise par le navigateur web à partir du poste client 2 La requête est reçue par le serveur web et transmise à la servlet concernée 3 La servlet détermine l'action à exécuter, et envoie un message aux objets d'accès au domaine (DAO) 4 Les DAO extraient les objets voulus de la couche de persistance, les modifient (RG) et les restockent 5 La servlet reçoit en retour ces objets modifiés par l'action exprimée par la requête 6 La servlet stocke les objets métier dans le contexte de session 7 La servlet transmet la requête, ainsi que le flux de réponse à la jsp (vue) 8 La jsp extrait le (les) objet métier modifiés du contexte pour constituer la page 9 La jspretoune la réponse à l'utilisateur, en réponse à sa requête

4. Une séquence requête-réponse avec gestion d’erreur et gestion de la navigation 1 Une requête http est émise par le navigateur web à partir du poste client 2 La requête est reçue par le serveur web et transmise à la servlet concernée 3 La servlet détermine l'action à exécuter, et envoie un message aux classes d'accès au domaine (DAO) 4 • Les DAO extraient les objets voulus de la couche de persistance, appliquent les règles de gestion et les restockent • En cas d’erreur (conversion, validation des règles métier, autre…), fin du cycle nominal • pas de restockage, poursuivre le cycle avec les beans erronés + messages pour correction par l’utilisateur 5 La servlet reçoit en retour ces objets modifiés par l'action exprimée par la requête (ou erronés) 6 La servlet stocke les objets métier dans le contexte de session 7 • La servlet transmet la requête, ainsi que le flux de réponse à la jsp (vue) • la servlet décide la vue cible (interprète le diagramme de navigation) (compte-tenu des erreurs) 8 La jsp cible extrait le (les) objet métier modifiés du contexte pour constituer la page 9 La jspretoune la réponse à l'utilisateur, en réponse à sa requête

5. Notre implémentation du cycle requête-réponse • étape 1: (il existe une session) décoder les événements depuis les paramètres de la requête http • étape 2:reconstituer l'objet de domaine depuis les paramètres de la requête http (formBean), et créer des copies: oldBean (sauvegarde) et newBean(objet final) • étape 3:retrouver la valeur de l'objet du domaine avant l'action, de préférence dans la couche de persistance, sinon dans notre contexte web, sinon prendre le 1° objet de la liste • étape 4: en cas de modification de l'objet conformément à une règle de gestion: • 4aappliquer les règles de gestion • 4bgérer les erreurs de validation, générer les messages d'erreur • 4cappliquer la nouvelle valeur sur le modèle si les règles sont vérifiées et faire persister l'objet modifié • 4dpréparer l'objet validé en tant que résultat, ou invalidé pour correction, à représenter dans la vue (newbean) • étape 5:appliquer les règles de navigation, déterminer la vue pour présenter le résultat de la requête • étape 6:diriger la requête vers la vue

6. Architecture JSF Source: tutorial primefaces ftp://ftp-developpez.com/tahe/fichiers-archive/jsf2-pf-pfm.pdf

7. Cycle requête-réponse pour JSF

8. Cycle requête-réponse pour JSF • en [A - RestoreView], grâce au champ caché javax.faces.ViewState la vue initialement envoyée au navigateur client est reconstituée. Ici, les composants de la page retrouvent la valeur qu'ils avaient dans la page envoyée. • en [B - ApplyRequests], les valeurs postées par le navigateur client sont utilisées pour mettre à jour les composants de la vue. Désormais la vue reflète la page telle que l'a modifiée l'utilisateur . • en [C- ProcessValidations], les valeurs postées sont vérifiées. (conversions String -> Types), mais aussi validations (intervalles de saisie, etc..). .Si la conversion échoue, fin du cycle request-response et la page P construite en [B] est renvoyée au navigateur client avec des messages d'erreur si l'auteur de la page P les a prévus. • en [D-UpdateModelValues], si tous les composants de la page P passent l'étape de conversion et de validation, leurs valeurs vont être affectées au modèle M de la page P. Si la valeur du champ de saisie généré à partir de la balise suivante : <h:inputText value="#{form.inputText}"/> est "jean", alors cette valeur sera affectée au modèle form de la page par exécution du code form.setInputText("jean"). • en [E-InvokeApplication], calcul de la clé de navigation (nom de la page XHTML à afficher) ; ou alors chercher une clé dans le document faces-config.xml. • en [F-RenderResponse], c’est la génération du flux en retour vers le navigateur.

9. MVC1 vs MVC2 Source: http://www.devmanuals.com/tutorials/java/struts/struts2/MVC1vsMVC2.html

10. MVC1 vs MVC2