Wzorce projektowe warstwy danych

Transkrypt

1 POLITECHNIKA GDAŃSKA WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI Katedra Architektury Systemów Komputerowych Jarosław Kuchta Instrukcja do laboratorium z przedmiotu Projektowanie Aplikacji Internetowych Wzorce projektowe warstwy danych Gdańsk 2013/14 1

2 Wprowadzenie W ćwiczeniu studenci mają za zadanie napisanie aplikacji internetowej w technologii Web Service lub WCF wykorzystującej jednocześnie trzy wzorce projektowe: Data Access Object Transfer Object Value List Handler 1. Wzorzec Data Access Object Wzorzec Data Access Object wynika ze spostrzeżenia, że dane komponentów biznesowych muszą być przechowywane w pamięci trwałej (masowej). Istnieje wiele typów pamięci trwałej. Dane mogą być przechowywane w zwykłym systemie plików, w repozytorium plików XML, w relacyjnych, obiektowo-relacyjnych i obiektowych bazach danych. Każdy z tych typów pamięci ma swój własny, unikatowy interfejs API. Również w zakresie tego samego typu pamięci (np. relacyjnych baz danych) API zależy od dostawcy określonego produktu zapewniającego przechowywanie danych (np. od producenta systemu bazy danych). Różnice w API powodują, że w przypadku zmiany dostawcy systemu przechowywanie danych zachodzi konieczność modyfikacji komponentów warstwy danych, a czasami również komponentów warstwy biznesowej. Z kolei uniezależnienie aplikacji od systemu przechowywania danych wymaga stworzenia uniwersalnego interfejsu dostępu do danych w pamięci masowej. Taki interfejs określa wzorzec DAO. We wzorcu DAO w warstwie danych występuje komponent (klasa i obiekt) dostępu do danych (komponent DAO) zapewniający jednolity dostęp do różnych źródeł danych. Źródłem danych dla DAO może być: system relacyjnej bazy danych (RDBMS) repozytorium plików XML system wymiany danych (B2B) usługa biznesowa dostępna przez protokół CORBA inny mechanizm przechowywania i udostępniania danych Komponent DAO udostępnia wspólny, uproszczony interfejs dostępu do danych, łączący możliwości różnych źródeł danych i ukrywający przed warstwą biznesową szczegóły implementacyjne dostępu do danych. Ponieważ interfejs DAO nie zmienia się wraz z implementacją źródła danych, więc uniezależnia warstwę biznesową od zastosowanego mechanizmu dostępu do danych. W skład wzorca wchodzą: Business Object obiekt biznesowy, którego dane są przechowywane Data Access Object główny obiekt wzorca, zapewnia transparentny dostęp do źródła danych Data Source źródło danych: baza danych, repozytorium XML etc. 2

3 Transfer Object przenosi dane z warstwy danych do obiektu biznesowego. Obiekt biznesowy (Business Object) wykorzystuje obiekt DAO (Data Access Object) do pozyskania lub utrwalenia danych. Obiekt DAO zawiera w sobie metody wykorzystujące różne źródła danych (Data Source). Źródłem danych może być system relacyjnej bazy danych, repozytorium plików XML itp. Obiekt DAO wystawia taki sam interfejs dla różnych źródeł danych, jednak klasa implementująca interfejs DAO może być zupełnie inna dla każdego typu źródła. Wzorzec DAO często współdziała ze wzorcem Transfer Object tworząc obiekt transferowy przenoszący dane z warstwy danych do obiektu biznesowego. Współdziałanie komponentów wzorca jest następujące: 1: Obiekt biznesowy tworzy instancję obiektu DAO. 2: Obiekt biznesowy wysyła żądanie danych do obiektu DAO. Ten z kolei: 2.1: Pobiera dane ze źródła i 2.2: Tworzy obiekt transferowy zapisując w nim pobrane dane. 2.3: Utworzony obiekt transferowy obiekt DAO zwraca do obiektu biznesowego. 3: Obiekt biznesowy pobiera dane w formie właściwości z obiektu transferowego, jak również może 4: zapisywać w nim dane w formie właściwości. 5: Po ewentualnej modyfikacji obiektu transferowego obiekt biznesowy wysyła do obiektu DAO żądanie zapisania danych. Wówczas obiekt DAO: 5.1: odczytuje z obiektu transferowego dane zmienione 5.2: i nie zmienione 5.3: i zapisuje je w źródle danych. 3

4 1.1. Strategie implementacyjne Strategia implementacji z automatycznym generowaniem kodu DAO Jeśli obiekt biznesowy wykorzystuje tylko jeden obiekt DAO, to jest możliwe utworzenie prostej relacji łączącej obiekt biznesowy, DAO i źródło danych. Można wówczas wykorzystać prosty generator kodu (ze środowiska implementacji) do wygenerowania kodu DAO. Metadane (dane opisujące dane) potrzebne dla tego generatora kodu są podawane przez dewelopera w osobnym pliku deskryptora. Alternatywnie generator kodu może przeprowadzać inspekcję istniejącej bazy danych (odczytywać tablice i ich pola) i tworzyć kod DAO na tej podstawie. W przypadku bardziej złożonego modelu danych warto wykorzystać wyspecjalizowane narzędzia umożliwiające graficzne przedstawienie odwzorowanie obiektów biznesowych w komponenty bazy danych (tablice i kwerendy). Strategia implementacji z fabryką obiektów DAO Bardziej elastyczną implementację wzorca DAO zapewnia zastosowanie wzorców Factory Method i Abstract Factory z GoF. Gdy nie przewiduje się zmiany systemu bazy danych możliwość wykorzystania wzorca Factory Method do tworzenia wielu obiektów DAO, po jednym dla każdej klasy trwałej. Gdy przewiduje się zmiany systemu bazy danych możliwość wykorzystania wzorca Abstract Factory do tworzenia różnych DAO odpowiednich do różnych systemów baz danych. 4

5 Strategia z metodą produkcji (Factory Method) Strategia z zastosowaniem wzorca Factory Method może mieć zastosowanie w przypadku, gdy nie przewiduje się zmiany implementacji źródła danych. Dla tego określonego źródła danych tworzy się fabrykę obiektów DAO (DAOFactory). Fabryka ta implementuje metody tworzące obiekty DAO (DAO_1, DAO_2) dla określonego typu źródła. Każdy z obiektów DAO jest tworzony dla jednej klasy biznesowej i udostępnia interfejs umożliwiający odczytanie i zapisanie właściwości tej klasy (DAO1, DAO2). Strategia z abstrakcyjną fabryką (Abstract Factory) Strategia z zastosowaniem wzorca Abstract Factory ma zastosowanie w przypadku, gdy przewiduje się różne implementacje źródła danych. W tej strategii fabryka obiektów DAO (DAO Factory) jest klasą abstrakcyjną; jej metody tworzenia obiektów DAO również są abstrakcyjne. Są one implementowane w konkretnych fabrykach DAO (XML DAO Factory, RDB DAO Factory, OODB DAO Factory), zapewnianych dla każdego źródła danych. Każdy z obiektów DAO dla tej samej klasy biznesowej implementuje ten sam, wspólny interfejs (klasy XML_DAO1, RDB_DAO1, OODB_DAO1 implementują interfejs DAO1; klasy XML_DAO2, RDB_DAO2, OODB_DAO2 implementują interfejs DAO2). 5

6 1.2. Przykład W przykładzie pokazano zastosowanie wzorca DAO w systemie składania zamówień firmy AnyComp. Klasa biznesowa (Client) uzyskuje dostęp do danych klientów firmy przechowywanych w bazie danych AnyCompDB poprzez obiekt DAO instancję klasy Customer_DAO implementującą interfejs CustomerDAO. Obiekt DAO przekazuje dane klientów przez tworzony obiekt transferowy klasy CustomerData. Dane klas trwałych: Customer, Account i Order są przechowywane w bazie danych. Dla każdej z klas zdefiniowano odpowiedni komponent DAO: Customer_DAO, Account_DAO i Order_DAO. Każdy komponent DAO implementuje własny interfejs. Fabryka DAO (DAO Factory) udostępnia dla klienta metody utworzenia instancji dla każdej z klas DAO. Fabryka DAO jest klasą, która implementuje metody tworzenia obiektów typu DAO dla różnych klas biznesowych. W tym przykładzie trzy metody tworzenia obiektów klasy "Customer_DAO", "Account_DAO" oraz "Order_DAO". Fabryka może mieć też inne metody wykorzystywane w pozostałej części implementacji. 6

7 Interfejs CustomerDAO deklaruje szereg metod dostępu do pamięci trwałej klasy Customer. insertcustomer wstawia do bazy dane nowego klienta; wynikiem jest identyfikator klienta (lub -1 w przypadku błędu) deletecustomer usuwa z bazy dane klienta o podanym identyfikatorze findcustomer wyszukuje w bazie dane klienta o podanym identyfikatorze; wynikiem jest obiekt zawierające dane klienta (w tym identyfikator) updatecustomer aktualizuje w bazie dane klienta W wielu przypadkach klasa trwała jest reprezentowana przez obiekt transferowy klasy CustomerData implementującej zdefiniowany interfejs. Klasa trwała reprezentująca klienta w modelu analitycznym (Customer) jest implementowana przez klasę obiektu transferowego (CustomerData). Do właściwości 7

8 wynikających z analizy dodawana jest właściwość ID przechowująca identyfikator klienta z bazy danych. Przykładowy kod klienta zawiera: 1. utworzenie faktorii DAO 2. utworzenie obiektu DAO 3. znalezienie danych i przekazanie ich przez obiekt transferowy 4. modyfikację danych w obiekcie transferowym po stronie klienta 5. aktualizację danych z obiektu transferowego po stronie serwera 8

9 2. Transfer Object Aplikacje implementują obiekty biznesowe po stronie serwera jako komponenty sesyjne lub komponenty encyjne. Przy tej architekturze komponenty klienckie, które chcą pozyskać dane od obiektów biznesowych, muszą wykorzystywać wiele metod dostępu do danych, wystawianych przez te obiekty za pośrednictwem interfejsów zdalnych. Wiele z tych metod to proste metody dostępu (get i set). Każde wywołanie metody obiektu biznesowego (nawet prostej) przez interfejs zdalny musi być traktowane jako wywołanie zdalne. Wywołania przechodzą przez kolejne warstwy architektury sieciowej niezależnie od tego, czy rzeczywiście są zdalne, czy też są skierowane do serwera lokalnego. Stąd na każde wywołanie nakładany jest duży narzut czasowy związany z wywołaniem poprzez warstwy sieciowe. Klienci najczęściej wymagają więcej niż jednego atrybutu danych dla jednej klasy biznesowej. Dla ich pozyskania muszą wywołać wiele metod. Wraz ze wzrostem liczby wywołań obiektów biznesowych przez ich zdalne interfejsu wydajność aplikacji znacząco maleje. Klienci zazwyczaj częściej potrzebują odczytywać, niż zapisywać dane. Dlatego zapewnienie wydajnego sposobu odczytywania danych zdalnych jest ważniejsze od wydajności zapisu danych. Rozwiązaniem tych problemów jest wzorzec Transfer Object, w którym dane dla komponentów warstw wyższych przekazuje się w postaci obiektowej. Instancja obiektu transferowego jest tworzona na żądanie klienta przez komponent serwerowy, atrybuty obiektu są wypełniane odpowiednimi danymi i obiekt w całości jest przesyłany do klienta. Klient odczytuje poszczególne dane (właściwości) z instancji obiektu transferowego po swojej stronie. Ponieważ do odczytania właściwości po stronie klienta nie potrzebny jest interfejs zdalny, więc tylko pojedyncze wywołanie interfejsu zdalnego jest potrzebne do przesłania całego pakietu danych. W skład wzorca Transfer Object wchodzą następujące komponenty: Client jest to klient komponentu biznesowego; może być to aplikacja użytkownika końcowego (w przypadku architektury z grubym klientem pozyskującym dane bezpośrednio z komponentów biznesowych), delegat biznesowy (p. wzorzec Business Delegate) albo inny obiekt biznesowy. Business Object obiekt biznesowy tworzy obiekt transferowy i zwraca na żądanie klienta; może być zaimplementowany jako: o Business Entity komponent encyjny o Business Session komponent sesyjny o Data Access Object komponent danych Transfer Object obiekt transferowy przenoszący dane dla klienta. Może to być instancja dowolnej serializowalnej klasy Javy. Klasa ta powinna mieć konstruktor określający, jakie dane są wymagalne dla utworzenia obiektu transferowego. Zazwyczaj pola obiektu są definiowane jako publiczne, dzięki 9

10 czemu nie potrzebne są metody dostępu. Jeśli obiekt transferowy ma być wykorzystywany również do zapisu danych i ma chronić niektóre pola, to potrzeba zadeklarować metody dostępu do odczytu wszystkich pól i ewentualnie do zapisu niektórych z nich. Współdziałanie komponentów jest następujące: 1. Klient wysyła do komponentu biznesowego żądanie pobrania danych. W odpowiedzi na to żądanie: 1.1. Komponent biznesowy tworzy instancję obiektu transferowego i wypełnia ją danymi. Instancja ta będzie przechowywana po stronie serwera i służyć do przyspieszenia obsługi kolejnych żądań Instancję obiektu transferowego komponent biznesowy zwraca do klienta Klient tworzy własną kopię obiektu transferowego, którą wykorzystuje do lokalnych operacji. 2 oraz 3. Klient pobiera poszczególne właściwości ze swojej kopii lokalnej. 10

11 2.1. Strategie implementacyjne W implementacji wzorca Transfer Object stosuje się cztery strategie: strategię z modyfikowalnym obiektem transferowym wówczas, gdy klient modyfikuje dane przekazywane przez obiekt transferowy strategię z wieloma obiektami transferowymi wówczas, gdy warstwa biznesowa jest mocno złożona strategię z rozszerzaniem obiektu transferowego przez komponent encyjny wówczas, gdy klient potrzebuje wszystkich danych komponentu encyjnego strategię z faktorią obiektów transferowych Pierwsze dwie strategie są stosowane wówczas, gdy obiekt biznesowy jest implementowany jako komponent sesyjny lub komponent encyjny. Pozostałe dwie tylko wtedy, gdy obiekt biznesowy jest implementowany jako komponent encyjny. Modyfikowalny obiekt transferowy W strategii z modyfikowalnym obiektem transferowym obiekt ten nie tylko przenosi dane z obiektu biznesowego do klienta, ale również zmiany dokonywane przez klienta z powrotem do obiektu biznesowego. Obiekt transferowy musi zapewniać metody modyfikacji danych. Metody te mogą zapewniać walidację wprowadzanych danych i spójność zawartości pól. Zmiany są dokonywane na lokalnej kopii obiektu transferowego. Zmiany te nie są widoczne dla obiektu biznesowego do czasu, gdy klient wywołuje metodę setdata() obiektu biznesowego. Wywołanie tej metody powoduje serializację lokalnej kopii obiektu transferowego i przesłanie jej do obiektu biznesowego. Obiekt biznesowy przyjmuje zmodyfikowaną kopię obiektu transferowego i złącza zmienione dane z danymi we własnej kopii. Operacja złączenia może komplikować projekt obiektu biznesowego i obiektu transferowego. Rozwiązanie praktyczne może polegać na aktualizacji tylko zmienionych danych. Zamiast porównywać kolejno właściwości obiektu transferowego z kopii serwerowej i kopii przesłanej od klienta można zastosować zbiór flag sygnalizujących, które właściwości zostały zmienione. Problemem projektowym pozostaje zapewnienie: odpowiedniej propagacji zmian do innych klientów, synchronizacja zmian dokonywanych przez różnych klientów, kontrola wersji danych 2.2. Przykład - modyfikowalny obiekt transferowy z flagami modyfikacji W przypadku, gdy obiekt transferowy jest modyfikowany przez klienta, wskazane jest zastosowanie flag zmian (ismodified). Wówczas metoda ustalenia (np. setfirstname) ustawia odpowiednią flagę (ale tylko wtedy, gdy klient rzeczywiście zmienia wartość pola). Wszystkie flagi powinny być skasowane (metoda clearismodified) wówczas, gdy dane zostaną zaktualizowane przez obiekt DAO. 11

12 3. Value List Handler Wzorzec Value List Handler ma zastosowanie w przypadku, gdy klient przegląda listę wartości (np. wyszukane strony w wyszukiwarce), a nie potrzebuje dla każdej wartości mieć cały obiekt zdalny. Niepraktyczne byłoby zwracanie całego zbioru wyszukanych rekordów. Lepiej jest przechować listę wyszukanych rekordów po stronie serwera i 12

13 podawać klientowi po kilka rekordów. Jeśli wielu klientów wyszukuje podobne dane, to przechowywana lista rekordów może być wielokrotnie wykorzystana. Klient może określać, po ile rekordów chce otrzymywać, oraz może poruszać się po przechowywanej liście zarówno w przód, jak i w tył. Lista wyników wyszukiwania może być przechowywana zgodnie ze wzorcem Value List Handler. Serwer może udostępniać przechowywane wyniki klientowi zgodnie z jego wymaganiami co do rozmiaru porcji rekordów i sposobu nawigacji. Główny komponent wzorca Value List Handler powinien implementować metody nawigacji po liście zdefiniowane w interfejsie Value List Iterator: getsize() podającą rozmiar listy getcurrentelement() podającą bieżący element z list w postaci obiektu transferowego getnextelements(int howmany) podają pewną ilość kolejnych elementów (obiektów transferowych) z listy getpreviouselements(int howmany) podają pewną ilość elementów (obiektów transferowych) z listy poprzedzających bieżący element resetindex() ustawiającą indeks bieżącego elementu na początek listy 3.1. Strategie implementacji W implementacji stosuje się dwie strategie: Implementacja przez zwykły obiekt - przydatna jedynie dla prostszych aplikacji Implementacja jako stanowy komponent sesji pełniący rolę fasady Kod implementacji wzorca przez zwykłą klasę może być następujący: 13

14 public class ValueListHandler implements ValueListIterator { protected List list; protected ListIterator listiterator; public ValueListHandler() { } protected void setlist(list list) { this.list = list; listiterator = list.listiterator(); } public Collection getlist() { return list; } public int getsize() { return list.size(); } public Object getcurrentelement() { int currindex = listiterator.nextindex(); return list.get(currindex); } public List getpreviouselements(int count) { int i = 0; Object object = null; LinkedList list = new LinkedList(); while (listiterator.hasprevious() && (i < count)){ object = listiterator.previous(); list.add(object); i++; } return list; } public List getnextelements(int count) { int i = 0; Object object = null; LinkedList list = new LinkedList(); while (listiterator.hasnext() && (i < count) ){ object = listiterator.next(); list.add(object); i++; } return list; } public void resetindex() { listiterator = list.listiterator(); }... } 14

15 4. Zadanie dla studentów Zaprogramować w środowisku Visual Studio albo J2EE aplikację rozproszoną składającą się z części serwerowej i części klienckiej. W części serwerowej zrealizować dwie warstwy: warstwę danych i warstwę usługową. W warstwie danych zaimplementować wzorzec DAO czytający dane z kolekcji danych zdefiniowanej w pamięci operacyjnej i zapisujący je w pliku na dysku twardym (bez bazy danych). Kolekcja powinna zawierać przynajmniej 30 rekordów danych. Format zapisu ma być czytelny dla człowieka (np. XML, JSON). W warstwie usługowej zaimplementować wzorzec Value List Handler buforujący dane pobrane z obiektu DAO i przekazujące je do części klienckiej w partiach po 10. Każdy rekord danych jest przekazywany w formie obiektu transferowego (Transfer Object). Aplikacja kliencka pobiera dane z warstwy usługowej przez interfejs Web Service. Dane prezentuje partiami dla użytkownika. Umożliwia przechodzenie do następnej lub poprzedniej partii danych. Aplikacja kliencka umożliwia użytkownikowi modyfikację wybranego rekordu danych i poprzez Web Service zmodyfikowanie pierwotnej kolekcji danych z zapisem jej w pliku. Bibliografia Rysunki i przykłady pochodzą z następujących źródeł: Literatura uzupełniająca: Gamma et al: Wzorce projektowe, WNT Warszawa Buschman et al: Pattern-Oriented Software Architecture Volume 1: A System of Patterns, Wyd. Wiley, Schmidt et al: Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects, Wyd. Wiley, 15