Architectures NTiers Paradigme MVC

10
Architectures NTiers Paradigme MVC f rancois.pfister@mines-ale s.fr 2012-2013 1

description

Architectures NTiers Paradigme MVC. f [email protected] 2012-2013. Architecture 4 Tiers – 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. - PowerPoint PPT Presentation

Transcript of Architectures NTiers Paradigme MVC

Page 2: Architectures  NTiers Paradigme MVC

2

Architecture 4Tiers – MVC2 simplifié

Client (tiers 1)serveur web (tiers 2)

session

CustomerServlet

BankServlet

Account.jsp

Bank.jsp

Customer.jsp

AccountServlet

persistance

Customer.java

Bank.java

Account.java

CustomerDao

AccountDao

BankDao

Serveur métier (tiers 3)

Modèle

Stocké à long termeStocké

temporairement

123456789

Vue

serveur données (tiers 4)

Contrôleur

NB: les séquences 2,4,7 et 8 schématisées comme des relations 1-1 peuvent être croisées

Page 3: Architectures  NTiers Paradigme MVC

3

Cycle requête-réponse nominal

123456789

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

Page 4: Architectures  NTiers Paradigme MVC

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

Page 5: Architectures  NTiers Paradigme MVC

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:• 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

Page 6: Architectures  NTiers Paradigme MVC

6

Architecture JSF

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

Page 7: Architectures  NTiers Paradigme MVC

7

Cycle requête-réponse pour JSF

Page 8: Architectures  NTiers Paradigme MVC

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.

Page 9: Architectures  NTiers Paradigme MVC

9

MVC1 vs MVC2

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

Page 10: Architectures  NTiers Paradigme MVC

10

MVC1 vs MVC2MVC1 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