Architectures NTiers Paradigme MVC francois.pfister@mines-ales.fr 2012-2013

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

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

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 jsp retoune la réponse à l'utilisateur, en réponse à sa requête

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: 4a appliquer les règles de gestion 4b gérer les erreurs de validation, générer les messages d'erreur 4c appliquer la nouvelle valeur sur le modèle si les règles sont vérifiées et faire persister l'objet modifié 4d pré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

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

Cycle requête-réponse pour JSF

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.

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

MVC1 vs MVC2 MVC1 MVC2 Associates the presentation logic with the business logic Isolates or disassociates the presentation logic from business logic Only one component is responsible for receiving request and sending response Separate components for receiving and  sending response. i.e. Controller & View Business logic and presentation Logic is combined so web designer and web developer cannot work simultaneously Since both logics are separate that's why designer and developer can work together Doesn't support reusability of application components Reusability of components Controller and model,both are JSP Controller is servlet and model is java class Tight coupling between page and model as data access is usually done using Custom tag or through java bean call One controller receives the request for the application and is responsible for taking appropriate action in response to each request