Rozdział 22
Poza granice modelu dwuwarstwowego
Gdy architektura klient/serwer weszła po raz pierwszy w modę, wydawało się
w miarę pewne, że rozwój tej technologii zmierzał będzie w kierunku zapełnienia
owej szerokiej luki, jaka istniała między kliencką a serwerową stroną  równania .
Reguły logiki aplikacji (business rules) można było co prawda konstruować na
serwerze, lecz wbudowanie istniejących po stronie serwera reguł logiki aplikacji
w realizowane po stronie klienta aplikacje okazało się trudnym zadaniem -
zwłaszcza na wczesnym etapie rewolucji związanej z architekturą klient/serwer.
Spodziewano się, że pewnego dnia serwery i klienci zaczną współpracować ze
sobą na tyle dobrze, iż ograniczenia takie zostaną pokonane i użytkownicy
końcowi otrzymają w pełni spójne aplikacje.
Na nieszczęście, w miarę jak coraz więcej producentów przechodziło na
technologię klient/serwer, cel ów stawał się coraz bardziej odległy. Programiści,
rozczarowani brakiem integracji między serwerami baz danych i narzędziami do
programowania aplikacji, zaczęli standardowo wbudowywać reguły logiki
aplikacji do programów. Nader często spotykało się systemy z regułami i więzami
(constraint) umieszczonymi całkowicie po stronie klienta i z żadnymi lub
przynajmniej niewieloma na serwerze bazy danych.
Chociaż było to najlepszym sposobem na zaopatrywanie użytkowników
końcowych we w pełni dopracowane aplikacje, to jego wada polegała na tym, że
zrealizowanych po stronie klienta więzów nie było bynajmniej łatwo
współużytkować w jednocześnie kilku narzędziach ani też przenosić na inne
platformy tak, jak więzów po stronie serwera. W efekcie programiści
implementacje tych samych reguł logiki aplikacji musieli konstruować
wielokrotnie - dla każdego narzędzia programistycznego, jakiego używali, i dla
każdej platformy, jaką wspierali. Ostatecznym rezultatem było mnóstwo
straconego czasu i tyle samo błędów powstałych przy przepisywaniu reguł logiki
aplikacji z jednego miejsca do drugiego.
Rozwiązaniem dla problemu tego i jeszcze paru innych, których istnienia we
wczesnym okresie rozwoju technologii klient/serwer nawet nie podejrzewano,
okazał się model wielowarstwowy (multi-tier). Zamiast tylko dwóch poziomów -
klienta i serwera - podejście wielowarstwowe dopuszcza ich wiele. W systemie
wielowarstwowym pomiędzy klientem a serwerem może być kilka poziomów,
z których każdy pełni specyficzną rolę.
642 Część IV
Delphi umożliwia programowanie aplikacji wielowarstwowych dzięki swym
czterem kluczowym technologiom:

brokerowi zdalnych danych - Remote Data Broker,

brokerowi więzów - Constraint Broker,

wsparciu przetwarzania aktówkowego - Briefcase computing,

wsparciu dla częściowych pakietów danych - Partial data package.
Każdą z nich omówię oddzielnie i pokażę, jak korzystać z nich w prawdziwych
aplikacjach.
Broker danych zdalnych
Istniejąca w Delphi technologia Brokera danych zdalnych (Remote Data Broker)
pozwala budować aplikacje typu  chudego klienta, nie wymagające wsparcia
obsługi baz danych (database engine) i sterowników na komputerze klienta.
Aplikacje te bowiem komunikują się poprzez sieć z serwerem aplikacji,
zawierającym komponenty TTable, TQuery i TStoredProc niezbędne do
uzyskania dostępu do serwera bazy danych. W serwerze aplikacji można
ustanowić więzy i reguły logiki aplikacji, które mogą być współużytkowane przez
te programy, które poprzez serwer aplikacji uzyskują dostęp do serwera bazy
danych. Zapewnia to centralizację reguł logiki aplikacji i jednocześnie pozwala
każdej aplikacji klienta funkcjonować tak, jakby w niej samej mieściły się reguły
logiki aplikacji.
UWAGA:
Chociaż prawdą jest, że model  chudego klienta pozwala budować aplikacje, nie
wymagające dołączania do nich obsługi bazy danych Borlanda, to aplikacje typu
chudego klienta wymagają jednak jakiegoś rodzaju mechanizmu do
komunikowania się z serwerem aplikacji. Funkcja taka znajduje się w pliku
DBCLIENT.DLL, który trzeba dystrybuować wraz z samą aplikacją chudego
klienta. Wydaje się, że DBCLIENT.DLL potrzebny jest tylko wtedy, gdy aplikacja
ta dokonuje zmian w danych i zmiany te wysyła do serwera, lecz by zabezpieczyć
się z każdej strony, najlepiej plik ten dołączać do każdej aplikacji omawianego
typu.
Aby zbudować Brokera danych zdalnych, należy wykonać następujące operacje:
1. Sprawdz
, czy serwer bazy danych InterBase pracuje.
2. Uruchom Eksplorator baz danych (Database Explorer) i zdefiniuj nowy alias
BDE o nazwie IB_EMPLOYEE, skojarzony z bazą danych EMPLOYEE.GDB,
Rozdział 22 Poza granice modelu dwuwarstwowego 643
dostarczaną wraz z Delphi (standardowo baza ta jest wC:\Program
Files\Borland\IntrBase\Examples).
3. Nowy alias kliknij prawym klawiszem myszy i wybierz Import to Dictionary.
Spowoduje to importowanie ograniczeń bazy danych oraz innych informacji
słownika danych z bazy InterBase do słownika danych Delphi.
4. Wyjdz
ze Eksploratora baz danych i powróć do Delphi.
5. Kliknij opcję menu File\New Application, aby rozpocząć nową aplikację
Delphi.
6. Kliknij opcję menu File\New i w oknie dialogowym New Items kliknij
dwukrotnie opcję Remote Data Module.
7. W kreatorze Remote Dataset Wizard podaj nazwę klasy (Class Name) dla
Brokera danych zdalnych.
8. Na formularzu brokera umieść komponent TTabel, komponent Database
i komponent Session.
9. Właściwość AutoSessionName komponentu Session ustaw na True.
10. Właściwość AliasName komponentu Database ustaw na IB_EMPLOYEE,
a jego właściwość DatabaseName na IB_EMPLOYEE. Właściwość
LoginPrompt ustaw na False i w polu edycyjnym właściwości Params wpisz
dwa następujące parametry: USER NAME=SYSDBA PASSWORD= masterkey
11. Jego właściwość HandleShared ustaw na True.
12. Właściwość DatabaseName komponentu Table ustaw na IB_EMPLOYEE,
a właściwość TableName na DEPARTMENT.
13. Prawym klawiszem myszy kliknij komponent Table i wybierz opcję
Export...from data module.
14. Zapisz projekt na dysku. Unit2 zachowaj jako RDB01.PAS, Unit1 jako
RDB00.PAS, a cały projekt jako RDB.DPR.
15. Teraz uruchom aplikację RDB, aby zarejestrować jej serwer COM. Zaraz po
załadowaniu można ją na powrót zamknąć.
Po utworzeniu brokera danych jesteśmy już gotowi do utworzenia korzystającej
z niego aplikacji. Zbudujemy zatem aplikację klienta danych zdalnych (RDC,
Remote Data Client), wykonując następujące czynności:
1. Rozpocznij nową aplikację Delphi, klikając File\New Application.
2. Na domyślnym formularzu umieść ClientDataSet, RemoteServer
i DataSource.
644 Część IV
3. Dodaj jeszcze do formularza komponent DBGrid.
4. Właściwość ServerName komponentu RemoteServer ustaw na
RDB.RemoteDataBroker.
5. Właściwość RemoteServer komponentu ClientDataSet ustaw na
RemoteServer1, zaś jego ProviderName na Table1 (Table1 odwołuje
się do tablicy DEPARTMENT w naszej aplikacji RDB).
6. Właściwość DataSet komponentu DataSource ustaw tak, by wskazywała na
komponent ClientDataSet, a właściwość DataSource komponentu
DBGrid tak, by wskazywała DataSource1.
7. Otwórz komponent ClientDataSet, ustawiając na True jego właściwość
Active.
Powinniśmy teraz w DBGrid zobaczyć dane z tabeli DEPARTMENT. Jeśli tak, to
nasze gratulacje - Czytelnik utworzył właśnie Brokera danych zdalnych (Remote
Data Broker) i aplikację kliencką.
Zanim pójdziemy dalej, zapamiętajmy nasz projekt na dysku. Moduł Unit1
zapiszmy jako RDC00.PAS, a projekt jako RDC.DPR ( RDC oznacza Remote
Data Client, czyli klient danych zdalnych).
Broker więzów
Prócz pośredniczenia w uzyskiwaniu danych, dostępny w Delphi komponent
modułu danych zdalnych może również pośredniczyć w realizowaniu więzów.
Może na przykład użyć informacji o więzach, importowanych z serwera bazy
danych, by uchronić nas przed samym nawet wysłaniem niepoprawnych danych do
serwera. Redukuje to ruch w sieci i przyspiesza pracę aplikacji. By przekonać się,
jak coś takiego działa, wykonajmy następujące czynności:
1. Ponownie załaduj aplikację RDB do Delphi.
2. Dwukrotnie klikając komponent Table wywołaj edytor pól i, aby dodać nowe
pola, naciśnij CTRL+A. Następnie dodaj do formularza wszystkie pola tabeli
DEPARTMENT naciskając OK.
3. Kliknij pole Budget w edytorze pól. W Inspektorze obiektów powinieneś
zobaczyć odpowiadający mu ImportedConstraint.
4. Zamknij edytor pól, zapisz aplikację i zrekompiluj ją.
5. Następnie aplikację RDC ponownie otwórz i uruchom.
Rozdział 22 Poza granice modelu dwuwarstwowego 645
6. Gdy aplikacja pojawi się na ekranie, zacznij redagować tabelę DEPARTMENT
przy pomocy kontrolki DBGrid i spróbuj wprowadzić niepoprawną wartość do
kolumny Budget (niepoprawna jest każdą wartość mniejsza od 10001).
Zobaczymy, że wartość ta zostanie natychmiast odrzucona, nawet bez wysyłania
jej do serwera. Broker więzów (Constraint Broker) implementuje bowiem swą
własną wersję więzów z serwera i przechwytuje wszystkie niepoprawne wartości
danych jeszcze zanim zostaną wysłane do serwera. Zwróćmy uwagę na włączenie
więzów do tekstu wyświetlonego komunikatu.
Wsparcie dla przetwarzania aktowkówego
Prócz pośrednictwa w przekazywaniu danych tam i z powrotem pomiędzy
aplikacją a serwerem aplikacji, Delphi może również przechowywać dane lokalnie.
Pozwala to na autonomiczną (off-line) pracę z danymi z serwera, z użyciem
techniki  aktówkowej . By zobaczyć, jak metoda ta działa w praktyce, wykonajmy
następujące kroki:
1. Zakończ aplikację RDC, o ile jeszcze działa.
2. Na głównym formularzu RDC umieść trzy komponenty Button,.
3. Pierwszy przycisk nazwij btSave, drugi btLoad, trzeci btSend.
4. Właściwość Caption przycisku btSave ustaw na  &Save locally ,
przycisku btLoad na  &Load local data , zaś przycisku btSend na  Send
changes to server .
5. Tak zmodyfikuj wymiary przycisków, by ich napisy widoczne były w całości.
6. Kliknij dwukrotnie bdSave i jego zdarzenie OnClik ustaw na:
ClientDataSet1.SaveToFile( C:\TESTLOCAL.DAT );
7. Kliknij dwukrotnie bdLoad i jego zdarzenie OnClik ustaw na:
ClientDataSet1.LoadFromFile( C:\TESTLOCAL.DAT );
8. Kliknij dwukrotnie bdSend i jego zdarzenie OnClik ustaw na:
ClientDataSet1.ApplyUpdates(0);
9. Zapisz aplikacje na dysku, po czym uruchom ją.
10. Gdy aplikacja ukaże się na ekranie, kliknij btSave.
11. Następnie odszukaj aplikację RDB (która została uruchomiona przez
mechanizm automatyzacji) i zamknij ją. Zignoruj komunikat o błędzie, który
zostanie wyświetlony, i kliknij Yes, aby zamknąć serwer aplikacji.
646 Część IV
12. Powróciwszy do RDC zauważysz, że możesz nadal pracować z załadowanym
zestawem danych. Dokonaj w nich kilku zmian, a następnie zapamiętaj je
lokalnie klikając przycisk btSave.
13. Zamknij aplikację RDC, a następnie uruchom ją raz jeszcze. Spowoduje to
ponowne otwarcie serwera aplikacji RDB. Zauważ, że dokonane zmiany
zostały utracone, ponieważ dane zostały na powrót pobrane z serwera bazy
danych.
14. Kliknij przycisk btLoad, aby załadować lokalną kopię danych. Teraz
powinieneś zobaczyć swoje modyfikacje.
15. Kliknij przycisk btSend, aby dokonane zmiany znalazły odzwierciedlenie
w serwerze. Jeśli teraz wyjdziesz z aplikacji i ponownie ją załadujesz, to
spostrzeżesz, że zmiany, które pierwotnie zapamiętane były lokalnie, zostały
przeniesione do kopii danych na serwerze. I to jest właśnie to, co mamy na
myśli używając metafory  aktówki - dane mogą być początkowo zapisywane
zewnętrznie i dopiero póz
niej, w dogodnej chwili, przenoszone, a mimo to
przez cały czas możemy pracować z nimi w sposób ciągły.
Częściowe pakiety danych
Inną, wielce użyteczną cechą zaimplementowanej w Delphi technologii brokera
danych jest możliwość ściągania (download) do aplikacji klienckiej częściowych
pakietów danych. Zamiast ładować cały zestaw danych rezultatu zapytania,
projektant aplikacji może zdecydować się na pobieranie za jednym razem tylko
małego podzbioru rekordów. Jest to szczególnie i w pierwszym rzędzie korzystne
w tych aplikacjach, które zwykle otrzymują jedynie niewielkie zestawy danych,
takich jak aplikacje typu pozycja główna/szczegóły (master/detail). By zobaczyć,
jak cecha ta uwidacznia się w praktyce, wykonajmy następujące kroki:
1. Zakończ aplikację RDC, jeśli jeszcze działa.
2. Umieść na formularzu komponent TStatusBar, który automatycznie
 doklei się do dolnej krawędzi formularza.
3. Jego właściwość SimplePanel ustaw w Inspektorze obiektów na True.
4. Kliknij komponent DataSource, a następnie w Inspektorze obiektów
dwukrotnie jego zdarzenie OnDataChange.
5. Do zdarzenie OnDataChange wpisz następujący kod:
With DataSource1.DataSet do
StatusBar1.SimpleText :=
Format( %d / %d , [RecNo, RecordCount]);
Rozdział 22 Poza granice modelu dwuwarstwowego 647
6. Właściwość PacketRecords komponentu ClientDataSet ustaw
w Inspektorze obiektów na 5. Spowoduje to, że z serwera pobieranych będzie
po pięć wierszy na raz. Ustawienie jej na -1 (domyślne) spowoduje pobieranie
wszystkich wierszy, natomiast 0 pobiera jedynie informacje ze słownika
danych.
7. Uruchom swoją aplikację. Podczas przewijania rekordów w komponencie
DBGrid zauważysz, że aplikacja pobiera pięć nowych wierszy za każdym
razem, gdy przekroczysz wielokrotność pięciu dotychczas wyświetlanych. Ten
poziom sterowania pozwala w pełni określić, jaka część zestawu rezultatów
będzie sprowadzana do klienta za jednym razem. Może to mieć decydujący
wpływ na szybkość działania, zwłaszcza przy pracy z bardzo dużymi tablicami
lub przy sięganiu do danych poprzez WAN.
Na rysunku 22.1 pokazano, jak powinna wyglądać aplikacja RDC.
Rysunek 22.1.
Nasza aplikacja
klienta danych
zdalnych w fazie
wykonania.