11 wzorce projektowe warstwy aplikacji - freeshell.demaciek/studia/7/par/wyklady/11...projektowanie...

1

[email protected]

[email protected]

Wzorce projektowe Wzorce projektowe

warstwy aplikacjiwarstwy aplikacji

Projektowanie Aplikacji RozproszonychProjektowanie Aplikacji Rozproszonych

2

Projektowanie Aplikacji

Rozproszonych 2/31Wzorce projektowe warstwy aplikacji

Wzorce projektowe warstwy Wzorce projektowe warstwy

aplikacjiaplikacji

�� Front Controller Front Controller

�� Zapewnia wspZapewnia wspóólny punkt obslny punkt obsłługi ugi ŜąŜądadańń dla komponentdla komponentóów w

warstwy prezentacjiwarstwy prezentacji

�� Dispatcher ViewDispatcher View

�� Zapewnia przekazywanie Zapewnia przekazywanie ŜąŜądadańń klienta do wybranych klienta do wybranych

komponentkomponentóów widoku (wybw widoku (wybóór widoku przez klienta)r widoku przez klienta)

�� Service To WorkerService To Worker

�� Zapewnia przekazywanie Zapewnia przekazywanie ŜąŜądadańń klienta do wybranych klienta do wybranych

komponentkomponentóów widoku (wybw widoku (wybóór widoku przez serwer)r widoku przez serwer)

3



Front ControllerFront Controller

4



Front ControllerFront Controller -- motywacjemotywacje

�� Mechanizm obsMechanizm obsłługi ugi ŜąŜądadańń warstwy prezentacji mowarstwy prezentacji moŜŜe e

bybyćć zdecentralizowany lub scentralizowany.zdecentralizowany lub scentralizowany.

�� Mechanizm zdecentralizowany powoduje problemy:Mechanizm zdecentralizowany powoduje problemy:

�� Redundancja kodu dostRedundancja kodu dostęępu do komponentpu do komponentóów usw usłługowychugowych

�� Brak spBrak spóójnojnośści w nawigacji mici w nawigacji mięędzy rdzy róóŜŜnymi widokaminymi widokami

�� Trudniejsza pielTrudniejsza pielęęgnacja (czgnacja (częęste zmiany w rste zmiany w róóŜŜnych miejscach)nych miejscach)

System rozproszony potrzebuje dla warstwy prezentacji centralnego punktu dostępowego, który będzie

integrował usługi, zarządzał odtwarzaniem zawartości, prezentacją treści i nawigacją. Jeśli takiego

centralnego punktu dostępowego brakuje, to pojawiają się następujące problemy:

•KaŜdy widok zapewnia sobie sam dostęp do komponentów usługowych, co powoduje redundancję kodu.

•KaŜdy widok sam organizuje nawigację, co moŜe powodować niespójność nawigacji między róŜnymi

widokami

•Sterowanie rozproszone jest trudniejsze w pielęgnacji i modyfikacji z powodu konieczności zmian w wielu

róŜnych miejscach

5



SpostrzeSpostrzeŜŜenia i wymaganiaenia i wymagania

�� WspWspóólne uslne usłługi systemowe rozpoczynajugi systemowe rozpoczynająą i i

kokońńczcząą przetwarzanie w tym samym przetwarzanie w tym samym ŜąŜądaniu.daniu.

�� Przy odtwarzaniu i manipulacji danymi Przy odtwarzaniu i manipulacji danymi

konieczne skonieczne sąą punkty decyzyjne.punkty decyzyjne.

�� Potrzebny jest centralny punkt monitorujPotrzebny jest centralny punkt monitorująący.cy.

�� Wiele rWiele róóŜŜnych widoknych widokóów odpowiada na podobne w odpowiada na podobne

ŜąŜądania biznesowe.dania biznesowe.

�� Logika zarzLogika zarząądzania widokami jest dodzania widokami jest dośćść zzłłooŜŜona.ona.

Ponadto zauwaŜono, Ŝe w systemach wykorzystujących wspólne komponenty usługowe:

•Komponenty usługowe często realizują operacje w pojedynczych Ŝądaniach. Dla przykładu usługi ochrony

potrzebują jednego Ŝądania dla uwierzytelnienia klienta.

•Potrzebne są punkty decyzyjne, w których klient będzie mógł podejmować decyzje co do odtwarzania

danych i ich zapisywania.

•Potrzebny jest centralny punkt monitorujący działania uŜytkownika i postęp przetwarzania w całej witrynie.

•Wiele róŜnych widoków odpowiada na podobne Ŝądania biznesowe.

•Logika zarządzania widokami jest często dość złoŜona.

6



RozwiRozwiąązaniezanie

�� Zastosowanie centralnego kontrolera frontowego Zastosowanie centralnego kontrolera frontowego ((Front ControllerFront Controller)) do obsdo obsłługi ugi ŜąŜądadańń..

�� Kontroler frontowy:Kontroler frontowy:�� zarzzarząądza obsdza obsłługugąą ŜąŜądadańń

�� wywowywołłuje usuje usłługi ochrony (ugi ochrony (npnp. uwierzytelnienia). uwierzytelnienia)

�� przekazuje przekazuje ŜąŜądania przetwarzania do komponentdania przetwarzania do komponentóów w ususłługowychugowych

�� zarzzarząądza wyborem odpowiedniego widoku w odpowiedzi na dza wyborem odpowiedniego widoku w odpowiedzi na ŜąŜądaniedanie

�� zarzzarząądza wyborem strategii tworzenia zawartodza wyborem strategii tworzenia zawartośścici

�� zarzzarząądza obsdza obsłługugąą bbłęłęddóóww

Przez zcentralizowanie sterowania Front Controller zmniejsza wielkość kodu Java w skrypletach zawartych

na stronach JSP wspierając wielokrotne wykorzystanie tego samego kodu.

Kontroler frontowy często współpracuje z komponentem przekaźnika (Dispatcher View), który jest

odpowiedzialny za zarządzanie widokami i nawigację. Przekaźnik wybiera widok i przekazuje sterowanie

do tego widoku. Przekaźnik moŜe być zawarty bezpośrednio w kontrolerze lub umieszczony w osobnym

komponencie.

ChociaŜ wzorzec Front Controller sugeruje centralne przetwarzanie Ŝądań, nie ogranicza on liczby

komponentów obsługujących Ŝądania. Aplikacja moŜe wykorzystywać wiele kontrolerów frontowych, po

jednym dla osobnego zbioru usług.

7



Struktura komponentStruktura komponentóóww

Clientrequests Front

Controller

«JSP»

JSP Front

«servlet»

Servlet

Front

Głównym komponentem wzorca jest Front Controller, który moŜe być zrealizowany w technologii serwletów

lub technologii JSP.

8



Przekazywanie Przekazywanie ŜąŜądadańń

ClientFront

ControllerDispatcher View Helper

1: Send (Request) 1.1: Delegate (Request) 1.1.1: Forward (Request)

2: Send (Request)2.1: Forward (Request)

3: Send (Request) 3.1: Forward (Request)

1. Klient wysyła Ŝądania do kontrolera frontowego.

1.1 Kontroler frontowy rozpoznaje Ŝądania i przekazuje je do przekaźnika

1.1.1 Przekaźnik wybiera określony widok i przekazuje do niego Ŝądanie klienta

2. W drugim przypadku klient wysyła Ŝądanie do kontrolera frontowego, a ten

2.1 bezpośrednio przekazuje Ŝądanie do wybranego przez siebie widoku

3. W trzecim przypadku klient wysyła do kontrolera frontowego Ŝądanie, które nie wymaga obsługi przez widok,

3.1 lecz przez obiekt pomocniczy

9



Strategie implementacyjneStrategie implementacyjne

�� Implementacja przez serwletImplementacja przez serwlet

�� momoŜŜliwoliwośćść wykorzystania interpretera komend wykorzystania interpretera komend

(wzorzec (wzorzec CommandCommand [[GoFGoF]]))

�� Implementacja przez stronImplementacja przez stronęę JSPJSP

10



PrzykPrzykłład ad –– implementacja implementacja

przez serwletprzez serwletpublic class EmployeeController extends HttpServlet { ... // Handles the HTTP GET method. protected void doGet(HttpServletRequest request, HttpServletResponse response) { processRequest(request, response); }

// Handles the HTTP POST method. protected void doPost(HttpServletRequest request, HttpServletResponse response) { processRequest(request, response); }

// Processes requests for both HTTP GET and POST methods protected void processRequest (HttpServletRequest equest, HttpServletResponse response) { String page;

// ApplicationResources provides a simple API for retrieving constants // and other preconfigured values ApplicationResources resource = ApplicationResources.getInstance(); // Use a helper object to gather parameter specific information. RequestHelper helper = new RequestHelper(request);

Command cmdHelper= helper.getCommand();

// Command helper perform custom operation

W implementacji przez serwlet:

•metoda doGet obsługuje Ŝądania przekazywane przez metodę HTTP GET

•metoda doPost obsługuje Ŝądanie przekazywane przez metodę HTTP POST

•obie te metody korzystają ze wspólnej procedury processRequest

•która wykorzystuje pomocniczy komponent interpretera komend (cmdHelper)

•i na podstawie odpowiedzi wybiera odpowiedni widok, do którego przekazuje Ŝądanie klienta (dispatch)

//-----------------------------------------------------------------------

public class Controller extends HttpServlet {

// Handles the HTTP GET method.

protected void doGet(HttpServletRequest request, HttpServletResponse response) {

processRequest(request, response);

}

// Handles the HTTP POST method.

protected void doPost(HttpServletRequest request,HttpServletResponse response) {


}

// Processes requests for both HTTP GET and POST methods.

protected void processRequest(HttpServletRequest request, HttpServletResponse response) {

String page;

// ApplicationResources provides a simple API for retrieving constants

// and other preconfigured values

ApplicationResources resource = ApplicationResources.getInstance();

// Use a helper object to gather parameter specific information.

RequestHelper helper = new RequestHelper(request);

Command cmdHelper= helper.getCommand();

// Command helper perform custom operation

page = cmdHelper.execute(request, response);

// dispatch control to view

11




przez stronprzez stronęę JSPJSP<%@page contentType="text/html"%><%@ page import="corepatterns.util.*" %><html><head><title>JSP Front Controller</title></head><body>

<h3><center> Employee Profile </h3>

<% <jsp:useBean id="employee" scope="request" class="corepatterns.util.EmployeeTO"/> <FORM method=POST > <table width="60%"> <tr> <td> First Name : </td> <td> <input type="text" name="<%=Constants.FLD_FIRSTNAME%>" value="<jsp:getProperty name="employee" property="firstName"/>"> </td> </tr> <tr> <td> Last Name : </td> <td> <input type="text" name="<%=Constants.FLD_LASTNAME%>" value="<jsp:getProperty name="employee" property="lastName"/>"> </td> </tr> <tr>

Implementacja przez stronę JSP, chociaŜ semantycznie równowaŜna, jest mniej popularna od

implementacji przez serwlet z dwóch powodów:

•PoniewaŜ kontroler frontowy przetwarza Ŝądania niekoniecznie związane z formatowaniem widoku, więc

implementacja tego komponentu przez stronę JSP wydaje się być nieporozumieniem.

•PoniewaŜ technologia JSP bazuje na znacznikach JSP w kodzie HTML, więc śledzenie wykonywania

programu jest mocno utrudnione.

//-----------------------------------------------------------------------

<%@page contentType="text/html"%>

<%@ page import="corepatterns.util.*" %>

<html>

<head><title>JSP Front Controller</title></head>

<body>

<h3><center> Employee Profile </h3>

<%

<jsp:useBean id="employee" scope="request" class="corepatterns.util.EmployeeTO"/>

<FORM method=POST >

<table width="60%">

<tr>

<td> First Name : </td>

<td>

<input type="text" name="<%=Constants.FLD_FIRSTNAME%>"

value="<jsp:getProperty name="employee" property="firstName"/>">

</td>

</tr>

<tr>

<td> Last Name : </td>

<td>

<input type="text" name="<%=Constants.FLD_LASTNAME%>"

value="<jsp:getProperty name="employee" property="lastName"/>">

</td>

</tr>

<tr>

<td> Employee ID : </td>

<td>

<input type="text"

12



Strategie adresowania kontroleraStrategie adresowania kontrolera

�� Adresowanie fizyczneAdresowanie fizyczne

�� http://some.server.com/resource1.jsphttp://some.server.com/resource1.jsp

�� http://some.server.com/servlet/Controllerhttp://some.server.com/servlet/Controller

�� Adresowanie logiczneAdresowanie logiczne

�� http://some.server.com/processhttp://some.server.com/process

�� process=resource1.jspprocess=resource1.jsp

�� process=servletControllerprocess=servletController

Przy przekazywaniu Ŝądań do kontrolera frontowego pojawia się problem adresowania tego kontrolera. Najprostszym rozwiązaniem jest jawne wpisanie nazwy fizycznego komponentu implementującego kontroler do URL, jak np.:

•http://some.server.com/resource1.jsp

•http://some.server.com/servlet/Controller

Oczywiście przy zmianie sposobu implementacji adresy URL będą musiały ulec zmianie. Dlatego wskazane jest uŜycie nazwy logicznej zasobu, np.:

•http://some.server.com/process

a następnie w konfiguracji witryny przypisanie nazwy logicznej do zasobu fizycznego:

•process=resource1.jsp

•process=servletController

13



Zalety i wady stosowania wzorcaZalety i wady stosowania wzorca

�� Centralizacja sterowaniaCentralizacja sterowania

�� wiwięększa ksza łłatwoatwośćść śśledzenia ledzenia ŜąŜądadańń

�� Uwaga: pojedynczy, wraUwaga: pojedynczy, wraŜŜliwy punkt systemuliwy punkt systemu

�� Wspomaganie zarzWspomaganie zarząądzania bezpieczedzania bezpieczeńństwemstwem

�� Pojedynczy punkt kontroli (mniej zasobPojedynczy punkt kontroli (mniej zasobóów)w)

�� Wspomaganie powtWspomaganie powtóórnego wykorzystania kodurnego wykorzystania kodu

�� WspWspóólny kod komponentlny kod komponentóów przeniesiony do w przeniesiony do

sterownikasterownika

Centralizacja sterowania

Kontroler frontowy stanowi centralny punkt obsługi Ŝądań. Ułatwia to śledzenie Ŝądań i ich obsługi. Z

drugiej jednak strony stanowi punkt wraŜliwy, potencjalnie naraŜony na błędy implementacji.

Wspomaganie zarządzania bezpieczeństwem

Kontroler frontowy moŜe realizować funkcje ochronne (np. uwierzytelnienia). PoniewaŜ taki punkt kontrolny

jest pojedynczy, to kontrola uwierzytelnienia jest łatwiejsza, a ponadto zuŜywa się na to mniej zasobów.

Wspomaganie powtórnego wykorzystania kodu

Kontroler frontowy powoduje, Ŝe często wykorzystywany kod komponentów warstwy prezentacji zostaje

przeniesiony do wspólnego sterownika.

14



Dispatcher ViewDispatcher View

15



Dispatcher ViewDispatcher View

�� Zapewnia przekazywanie Zapewnia przekazywanie ŜąŜądadańń klienta do klienta do

okreokreśślonego widokulonego widoku

�� ŁąŁączy wzorce czy wzorce Front ControllerFront Controller i i View View

HelperHelper

�� W odrW odróóŜŜnieniu od wzorca nieniu od wzorca Service Service TTo o

WorkerWorker rola przekarola przekaźźnikanika ograniczona lub ograniczona lub

umiarkowanaumiarkowana

Wzorzec Dispatcher View jest stosowany w aplikacji złoŜonej z wielu widoków. Zapewnia

przekazywanie Ŝądań klienta do odpowiedniego widoku wówczas, gdy to serwer

decyduje, do którego widoku musi trafić Ŝądanie.

Wzorzec łączy w sobie rozwiązania wzorców Front Controller i View Helper (ten drugi wzorzec

zdefiniowany jest w warstwie prezentacji).

Wzorzec Dispatcher View jest podobny do wzorca Service To Worker, ale w odróŜnieniu od niego rola

komponentu przekazującego Ŝądania jest ograniczona lub umiarkowana.

16



Ograniczona rola przekaOgraniczona rola przekaźźnikanika

�� Do wyboru widoku nie wykorzystuje siDo wyboru widoku nie wykorzystuje sięę

zewnzewnęętrznych zasobtrznych zasobóów. w.

�� Informacje zawarte w Informacje zawarte w ŜąŜądaniu sdaniu sąą wystarczajwystarczająące ce

do okredo okreśślenia widoku, do ktlenia widoku, do któórego trzeba rego trzeba

przekazaprzekazaćć ŜąŜądanie.danie.PrzykPrzykłład:ad:

http://some.server.com/servlet/Controller?next=login.jsphttp://some.server.com/servlet/Controller?next=login.jsp

Ograniczona rola przekaźnika polega na tym, Ŝe do wyboru widoku aplikacja nie potrzebuje dostępu do

Ŝadnych dodatkowych zasobów. Oznacza to, Ŝe dane przekazywane przez klienta w Ŝądaniu są

wystarczające do określenia widoku, do którego trzeba przekazać Ŝądanie. Dane są zakodowane w URL

poprzez parametry Ŝądania, np.:

http://some.server.com/servlet/Controller?next=login.jsp

17



Umiarkowana rola przekaUmiarkowana rola przekaźźnikanika

�� Klient przekazuje Klient przekazuje ŜąŜądanie bezpodanie bezpośśrednio do rednio do

sterownika, z parametrem kwerendy opisujsterownika, z parametrem kwerendy opisująącym cym

akcjakcjęę do podjdo podjęęcia:cia:

PrzykPrzykłładad

http://some.server.com/servlet/Controller?action=loginhttp://some.server.com/servlet/Controller?action=login

Umiarkowana rola przekaźnika polega na tym, Ŝe wybór widoku następuje na podstawie parametrów

przekazywane przez klienta, np.:

http://some.server.com/servlet/Controller?action=login

18



Struktura komponentStruktura komponentóóww

Clientrequests

«servlet»

Front

Controller

«JSP»

ViewDispatcher

delegates dispatches

1 1..*

Helper

uses

1

*

Głównym komponentem wzorca jest przekaźnik (Dispatcher). Komponent ten często współdziała z

kontrolerem frontowym (Front Controller) implementowanym w formie serwletu. Przekazuje Ŝądania z

kontrolera do wybranego widoku (np. strony JSP). Widok moŜe wykorzystywać dodatkowe obiekty

pomocnicze.

19



WspWspóółłdziadziałłanie komponentanie komponentóóww

Client

«servlet»

Front

Controller

«JSP»

ViewDispatcher Helper

1: Request1.1: Delegate

1.1.1: Dispatch

1.1.1.1: Retrieve

1.1.1.1.1: Get Data

1.1.1.2: Get Property

Value

Object

Business

Service

Przy współdziałaniu komponentów we wzorcu Dispatcher View:

1. Klient przesyła Ŝądanie do kontrolera frontowego

1.1 Kontroler rozpoznaje Ŝądanie i przesyła je do przekaźnika

1.1.1 Przekaźnik wybiera widok (stronę JSP) na podstawie danych zawartych w Ŝądaniu

1.1.1.1 Widok korzysta z obiektu pomocniczego, który

1.1.1.1.1 pobiera dane z komponentu usługowego zwracającego obiekt transferowy

1.1.1.2 który przenosi dane dla widoku

20



Strategie implementacyjneStrategie implementacyjne

�� Dla widokDla widokóóww

�� przez serwletprzez serwlet

�� przez JSPprzez JSP

�� Dla obiektu pomocniczegoDla obiektu pomocniczego

�� przez komponenty EJBprzez komponenty EJB

�� przez przez custom tagscustom tags

Komponenty widoku mogą być implementowane w technologii serwletów albo jako strony JSP.

W pierwszym przypadku obiekty pomocnicze są implementowane jako komponenty EJB, a w drugim przez

znaczniki uŜytkownika (custom tags).

21



Strategia "przekaStrategia "przekaźźnik w nik w

sterowniku"sterowniku"Client

«JSP»


1: Request

1.1: Dispatch

1.1.1: Retrieve

1.1.1.1: Get Data

1.1.2: Get Property

Value

Object

Business

Service

Wzorzec Dispatcher View i Front Controller mogą być zaimplementowane w jednym komponencie.

22



Strategia "przekaStrategia "przekaźźnik w nik w

widoku"widoku"Client

«JSP»

View

«JSP»


1: Request1.1: Delegate

1.1.1: Dispatch

1.1.1.1: Retrieve

1.1.1.1.1: Get Data


Value

Object

Business

Service

Wzorzec Dispatcher View moŜe być teŜ zaimplementowany w komponencie widoku w technologii JSP.

23



PrzykPrzykłład ad –– implementacja z implementacja z

kontrolerem w serwleciekontrolerem w serwleciepublic class Controller extends HttpServlet {

// Handles the HTTP GET method. protected void doGet(HttpServletRequest request, HttpServletResponse response) { processRequest(request, response); }

// Handles the HTTP POST method. protected void doPost(HttpServletRequest request,HttpServletResponse response) { processRequest(request, response); }

// Processes requests for both HTTP GET and POST methods. protected void processRequest(HttpServletRequest request, HttpServletResponse response) { String nextview; ... nextview = request.getParameter("nextview"); ... dispatch(request, response, nextview); }

// Dispatcher method protected void dispatch(HttpServletRequest request, HttpServletResponse response, String page) { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(page); dispatcher.forward(request, response);

W poniŜszym przykładzie wzorzec Dispatch View jest implementowany wraz ze wzorcem Front Controller

przez serwlet. Od poprzedniego przykładu implementację odróŜnia metoda processRequest, w której

nazwę następnego widoku (nextview) pobiera się z parametru Ŝądania.

//-----------------------------------------------------------------------

public class Controller extends HttpServlet {

// Handles the HTTP GET method.

protected void doGet(HttpServletRequest request, HttpServletResponse response) {


}

// Handles the HTTP POST method.

protected void doPost(HttpServletRequest request,HttpServletResponse response) {


}

// Processes requests for both HTTP GET and POST methods.

protected void processRequest(HttpServletRequest request, HttpServletResponse response) {

String nextview;

...

nextview = request.getParameter("nextview");

...

dispatch(request, response, nextview);

}

// Dispatcher method

protected void dispatch(HttpServletRequest request, HttpServletResponse response, String page) {

RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(page);

dispatcher.forward(request, response);

}

}

24




przez stronprzez stronęę JSPJSP<%@ taglib uri="/web-INF/corepatternstaglibrary.tld" prefix="corepatterns" %>

<html><head><title>AccountDetails</title></head><body>

<corepatterns:AccountQuery queryParams="custid,acctkey" scope="request" />

<h2><center> Account Detail for <corepatterns:Account attribute="owner" /></h2> <br><br>

<tr> <td>Account Number :</td> <td><corepatterns:Account attribute="number" /></td></tr>

<tr> <td>Account Type:</td> <td><corepatterns:Account attribute="type" /></td></tr>

<tr> <td>Account Balance:</td> <td><corepatterns:Account attribute="balance" /></td></tr>

<tr>

Implementacja przez stronę JSP, chociaŜ semantycznie równowaŜna, jest mniej popularna od

implementacji przez serwlet z dwóch powodów:

•PoniewaŜ kontroler frontowy przetwarza Ŝądania niekoniecznie związane z formatowaniem widoku, więc

implementacja tego komponentu przez stronę JSP wydaje się być nieporozumieniem.

•PoniewaŜ technologia JSP bazuje na znacznikach JSP w kodzie HTML, więc śledzenie wykonywania

programu jest mocno utrudnione.

//-----------------------------------------------------------------------

<%@ taglib uri="/web-INF/corepatternstaglibrary.tld" prefix="corepatterns" %>

<html>

<head><title>AccountDetails</title></head>

<body>

<corepatterns:AccountQuery queryParams="custid,acctkey" scope="request" />

<h2><center> Account Detail for <corepatterns:Account attribute="owner" /></h2> <br><br>

<tr>

<td>Account Number :</td>

<td><corepatterns:Account attribute="number" /></td>

</tr>

<tr>

<td>Account Type:</td>

<td><corepatterns:Account attribute="type" /></td>

</tr>

<tr>

<td>Account Balance:</td>

<td><corepatterns:Account attribute="balance" /></td>

</tr>

<tr>

<td>OverDraft Limit:</td>

<td><corepatterns:Account attribute="overdraftLimit" /></td>

</tr>

<table border=3>

25



Zalety wzorcaZalety wzorca

�� Centralizuje sterowanie i uCentralizuje sterowanie i ułłatwia powtatwia powtóórne rne

uuŜŜycie kodu i utrzymanie koduycie kodu i utrzymanie kodu

�� UUłłatwia podziaatwia podziałł aplikacji na warstwyaplikacji na warstwy

�� UUłłatwia podziaatwia podziałł rróól mil mięędzy projektantdzy projektantóóww

Centralizuje sterowanie i ułatwia powtórne uŜycie kodu i utrzymanie kodu

Centralizacja sterowania, wykorzystanie wspólnego kodu w wydzielonym komponencie oraz ułatwienie

pielęgnacji kodu to te same zalety, co w przypadku wzorca Front Controller.

Ułatwia podział aplikacji na warstwy

Wykorzystanie obiektów pomocniczych jasno oddziela warstwę prezentacji od przetwarzania w warstwie

aplikacji. Stanowi lepsze rozwiązanie od skrypletów, które w większych projektach przestają być

wystarczające.

Ułatwia podział ról między projektantów

Wydzielenie logiki aplikacji z warstwy prezentacji ułatwia podział ról między projektantów na tych, którzy

zajmują się wizualną stroną projektu i tych, którzy zarządzają logiką aplikacji.

26



Service To WorkerService To Worker

27



Service To WorkerService To Worker

�� Podobnie jak wzorzec Podobnie jak wzorzec Dispatcher ViewDispatcher View łąłączy czy

wzorce wzorce Front ControllerFront Controller i i View HelperView Helper w w

komponencie przekakomponencie przekaźźnika.nika.

�� PrzekaPrzekaźźnik monik moŜŜe bye byćć bardziej zaawansowany.bardziej zaawansowany.

�� MoMoŜŜe wywoe wywołływaywaćć ususłługi biznesowe dla ugi biznesowe dla

okreokreśślenia, ktlenia, któóry widok jest najbardziej ry widok jest najbardziej

odpowiedni.odpowiedni.

Wzorzec Service To Worker spełnia tę samą rolę co Dispatcher View. RóŜnica polega na tym, Ŝe rola

przekaźnika moŜe być duŜo większa niŜ we wzorcu Dispatcher View. Przekaźnik sam określa, do którego

widoku wysłać Ŝądanie klienta. W tym celu moŜe wykorzystywać usługi biznesowe.

28



Struktura wzorcaStruktura wzorca

Clientrequests

«servlet»

Front

Controller

«JSP»

ViewDispatcher

delegates dispatches

1 1..*

Helper

uses

1

*

1

1

**

usesuses

RóŜnica w strukturze wzorca Service To Worker w stosunku do Dispatcher View polega na tym, Ŝe nie

tylko komponent widoku korzysta z obiektów pomocniczych, ale równieŜ przekaźnik i kontroler frontowy.

29



WspWspóółłdziadziałłanie komponentanie komponentóóww

Client

«servlet»

Front

Controller

«JSP»


1: Request

1.2: Delegate

1.1: Retrieve

1.2.1.1: Get Data


Value

Object

Business

Service

1.1.1: Get Data

1.2.2: Dispatch

1.2.1: Choose View

Przy współdziałaniu komponentów we wzorcu Service To Worker:

1. Klient przesyła Ŝądanie do kontrolera frontowego

1.1 Kontroler odtwarza obiekt pomocniczy (np. poprzez zapamiętany identyfikator)

1.1.1 Obiekt pomocniczy pobiera dane z komponentu usługowego

1.2 Kontroler przekazuje Ŝądanie klienta wraz z danymi z komponentu usługowego do przekaźnika

1.2.1 Ten wykorzystuje obiekt pomocniczy do ustalenia, który widok będzie najbardziej odpowiedni

1.2.1.1 Obiekt pomocniczy moŜe potrzebować więcej danych z komponentu usługowego

1.2.2 Przekaźnik przekazuje Ŝądanie do wybranego widoku, który

1.2.2.1 pobiera dane z obiektu transferowego zwróconego przez komponent usługowy

30



Strategie i zaletyStrategie i zalety

�� jak dla wzorca jak dla wzorca Dispatcher ViewDispatcher View

Strategie implementacyjne wzorca oraz zalety jego stosowania są takie same jak dla wzorca Dispatcher

View.

31



LiteraturaLiteratura

PrzykPrzykłłady i rysunki pochodzady i rysunki pochodząą z nastz nastęępujpująących cych źźrróódedełł::

�� http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontCohttp://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.htmlntroller.html

�� http://java.sun.com/blueprints/corej2eepatterns/Patterns/Dispatchttp://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.htmlherView.html

�� http://java.sun.com/blueprints/corej2eepatterns/Patterns/Servicehttp://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceToWorker.htmlToWorker.html

11 wzorce projektowe warstwy aplikacji - freeshell.demaciek/studia/7/par/wyklady/11...projektowanie...

Documents