P
P
R
R
O
O
J
J
E
E
K
K
T
T
O
O
W
W
A
A
N
N
I
I
E
E
D
D
O
O
S
S
T
T
Ę
Ę
P
P
U
U
D
D
O
O
B
B
A
A
Z
Z
Y
Y
D
D
A
A
N
N
Y
Y
C
C
H
H
W
W
A
A
R
R
S
S
T
T
W
W
A
A
T
T
R
R
W
W
A
A
Ł
Ł
O
O
Ś
Ś
C
C
I
I
Dokument techniczny
P
P
R
R
O
O
J
J
E
E
K
K
T
T
O
O
W
W
A
A
N
N
I
I
E
E
D
D
O
O
S
S
T
T
Ę
Ę
P
P
U
U
D
D
O
O
B
B
A
A
Z
Z
Y
Y
D
D
A
A
N
N
Y
Y
C
C
H
H
W
W
A
A
R
R
S
S
T
T
W
W
A
A
T
T
R
R
W
W
A
A
Ł
Ł
O
O
Ś
Ś
C
C
I
I
Dokument techniczny
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
2
Spis Treś ci
Architektura aplikacji wykorzystującej bazę danych. ................................ .................... 3
Rodzaje warstw dostępu do danych. ................................ ................................ ......... 4
Dostęp do danych w klasach biznesowych................................. ................................ .. 5
Klasy dostępu do danych. ................................ ................................ ....................... 6
Deskryptory odwzorowań. ................................ ................................ ...................... 6
Projektowanie warstwy trwałoś ci. ................................ ................................ ............ 7
Samodzielne tworzenie warstwy a zakup................................. ................................ ... 7
Wymagania. ................................ ................................ ................................ ........ 7
Hermetyzacja dostę pu do danych................................. ................................ .............. 8
Minimalizacja ograniczeń w stosowaniu technik obiektowo zorientowanych............................. 8
Rozszerzalność . ................................ ................................ ................................ .... 8
Formułowanie zapytań................................. ................................ ........................... 8
Wsparcie dla czę ściowego odczytu................................. ................................ ............. 9
Mechanizmy opó źnionego odczytu. ................................ ................................ ............. 9
Mechanizmy opó źnionego zapisu. ................................ ................................ ............... 9
Ró żne mechanizmy trwałości. ................................ ................................ ................... 9
Bazy danych od ró żnych dostawcó w. ................................ ................................ ........... 9
Połączenia z wieloma bazami danych w jednej sesji................................. ....................... 10
Literatura. ................................ ................................ ................................ ....... 10
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
3
A
A
r
r
c
c
h
h
i
i
t
t
e
e
k
k
t
t
u
u
r
r
a
a
a
a
p
p
l
l
i
i
k
k
a
a
c
c
j
j
i
i
w
w
y
y
k
k
o
o
r
r
z
z
y
y
s
s
t
t
u
u
j
j
ą
ą
c
c
e
e
j
j
b
b
a
a
z
z
ę
ę
d
d
a
a
n
n
y
y
c
c
h
h
Nowoczesne narzę dzia programistyczne umoż liwiają bardzo szybkie zbudowanie interfejsu
graficznego, czerpiącego dane z bazy relacyjnej. Elementy graficzne, wspó łpracujące z bazą
danych (data-aware controls) ułatwiają prezentację i edycję danych, a komponenty dostę pu do
danych upraszczają kodowanie przetwarzań. Bardzo czę sto za pomocą jednej spó jnej biblioteki klas
moż na operować na ró żnych bazach danych, troszcząc się tylko o specyfikę dialektu SQL,
używanego przez tę czy inną bazę .
Za pomocą technik RAD moż na bardzo szybko budować prototypy albo aplikacje jednorazowe, ale
duże systemy szybko tracą pielę gnowalność . W przypadku dużych systemó w o długim cyklu ż ycia
stosuje się zwykle architekturę tró jwarstwową.
Rys 1. Architektura tró jwarstwowa.
System stworzony zgodnie z zasadami tej architektury składa się z trzech składowych.
a)
Pierwsza warstwa jest odpowiedzialna za kontakt z użytkownikiem i zawiera obiekty interfejsu
graficznego. Jest z natury bardzo silnie związana z określonym środowiskiem
programistycznym.
b)
Druga warstwa składa się z obiektó w związanych z dziedziną problemu, jest wię c
odwzorowaniem modelu poję ciowego, powstałego w wyniku analizy. Składają się na nią obiekty
biznesowe, odwzorowujące poję cia z dziedziny problemu, oraz obiekty sterujące – obiekty
odpowiedzialne za sterowanie przebiegiem przypadkó w użycia.
c)
Trzecia warstwa jest odpowiedzialna za dostę p do danych. Ma zapewniać spó jny i jednolity
dostę p do danych i jest silnie powiązana zaró wno ze środowiskiem programistycznym (albo
standardem dostę pu np. ODBC lub JDBC), jak i bazą danych.
Warstwa prezentacji
Warstwa dziedziny problemu
Warstwa bazy danych
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
4
Dobre rozwiązanie w architekturze tró jwarstwowej charakteryzuje się słabymi związkami, a co za
tym idzie niewielkim wzajemnym wpływem poszczegó lnych warstw. Dzię ki temu zmiany w
schemacie bazy danych są odzwierciedlane tylko w warstwie bazy danych, a zmiany w sposobie
prezentacji nie wpływają ani na warstwę dziedziny problemu, ani na warstwę bazy danych.
Podobnie zmiany w algorytmach biznesowych implikują modyfikacje wyłącznie w warstwie
dziedziny problemu. Najstaranniejsze rozwiązania umożliwiają nawet zmianę technologii
wykorzystywanej przez jedną warstwę (np. zmianę z okienek Windows na strony HTML), bez
wpływu na pozostałe warstwy.
Wyprodukowanie aplikacji o architekturze tró jwarstwowej jest bardziej pracochłonne, niż
wykorzystanie wprost technik RAD, i koncepcyjnie trudniejsze, ale daje kilka istotnych korzyści.
a)
Zaró wno projekt, jak i kod mają konsekwentną, łatwą do czytania strukturę . Każda warstwa
jest skoncentrowana na jednym aspekcie, dzię ki czemu jest prosta. Skutkiem tego:
•
szansa na zakończenie projektu sukcesem jest wię ksza,
•
pielę gnacja produktu jest łatwiejsza.
b)
Zmiany o charakterze technologicznym wymagają przepisania tylko jednej warstwy, wię c są
realne.
R
R
o
o
d
d
z
z
a
a
j
j
e
e
w
w
a
a
r
r
s
s
t
t
w
w
d
d
o
o
s
s
t
t
ę
ę
p
p
u
u
d
d
o
o
d
d
a
a
n
n
y
y
c
c
h
h
Narzę dzia typu RAD nie wspierają architektury tró jwarstwowej. Najłatwiej za ich pomocą tworzyć
aplikacje składające się tylko z warstwy prezentacji i warstwy dostę pu do danych.
Rys 2. Architektura aplikacji typu RAD.
Takie rozwiązanie, jakkolwiek bardzo produktywne, wiąż e ściśle sposó b prezentacji ze strukturą
bazy danych. Nawet drobne zmiany w schemacie muszą być odzwierciedlone w interfejsie
graficznym. Ponieważ nie ma tu miejsca na obiekty biznesowe, pojawiają się zasadnicze problemy
z wykorzystaniem wynikó w analizy. Funkcjonalność obiektó w biznesowych jest implementowana
czę ściowo w bazie danych jako triggery i procedury składowane, a czę ściowo w interfejsie
Warstwa prezentacji
Warstwa bazy danych
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
5
graficznym w kodzie obsługi zdarzeń. Bardziej ambitni projektanci wprowadzają obiekty sterujące,
dzię ki któ rym przebiegi przypadkó w użycia stają się bardziej czytelne.
Rys 3. Aplikacja typu RAD wzbogacona o obiekty sterujące.
Obiekty sterujące mogą też być wykorzystane do implementowania funkcjonalności obiektó w
biznesowych, dzię ki czemu uzyskujemy pewien substytut pełnej warstwy biznesowej.
Niestety problem powiązania warstwy prezentacji ze strukturą bazy danych pozostaje
nierozwiązany. Ró wnież szczątkowa warstwa biznesowa pełna jest zapytań SQL.
D
D
O
O
S
S
T
T
Ę
Ę
P
P
D
D
O
O
D
D
A
A
N
N
Y
Y
C
C
H
H
W
W
K
K
L
L
A
A
S
S
A
A
C
C
H
H
B
B
I
I
Z
Z
N
N
E
E
S
S
O
O
W
W
Y
Y
C
C
H
H
Najprostszym sposobem rozwiązania problemu dostę pu do bazy danych jest umieszczenie kodu
związanego z odczytem i zapisem w klasach biznesowych.
Rys 4. Najprostsze rozwiązanie warstwy dostę pu do danych.
W takim przypadku kod aplikacji powstaje dość szybko, ale funkcjonalność obiektó w biznesowych
zostaje związana ze schematem bazy danych. Zmiany w schemacie bę dą wymagały uwzglę dnienia w
kodzie warstwy dziedziny problemu. Korzyścią jest to, że warstwa prezentacji i obiekty sterujące
są wolne od kodu SQL.
Warstwa prezentacji
Warstwa bazy danych
Warstwa obiektó w
sterujących
Baza danych
S
Klasy
biznesowe
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
6
K
K
L
L
A
A
S
S
Y
Y
D
D
O
O
S
S
T
T
Ę
Ę
P
P
U
U
D
D
O
O
D
D
A
A
N
N
Y
Y
C
C
H
H
Znacznie skuteczniejszym rozwiązaniem jest wprowadzenie klas zarządzających odczytem i
zapisem.
Rys 5. Rozwiązanie z klasami dostę pu do danych.
Odwołania do bazy za pośrednictwem SQL są zgrupowane w warstwie dostę pu do danych, wię c
zmiany w schemacie bazy nie wpływają ani na warstwę prezentacji, ani na warstwę dziedziny
problemu. Niestety bezpośrednio zakodowany SQL wraz ze zmianami schematu może wymagać
dużych modyfikacji.
D
D
E
E
S
S
K
K
R
R
Y
Y
P
P
T
T
O
O
R
R
Y
Y
O
O
D
D
W
W
Z
Z
O
O
R
R
O
O
W
W
A
A
Ń
Ń
Rys 6. Warstwa trwałości z deskryptorami odwzorowań.
Najbardziej zaawansowanym rozwiązaniem jest warstwa trwałości bez rę cznie wprowadzonego
kodu SQL Taka warstwa zawiera opisy odwzorowań pomię dzy klasami biznesowymi i tabelami bazy
relacyjnej i generuje kod SQL na ich podstawie. Pisanie kodu transformującego jest znacznie
łatwiejsze, niż w dwó ch poprzednich przypadkach (ze wzglę du na jego deklaratywny charakter), a
wszelkie zmiany w schemacie bazy mogą być łatwo uwzglę dniane. W szczegó lnych przypadkach
opisy odwzorowań mogą być przechowywane w zewnę trznych plikach, zwykle stosuje się do tego
Baza danych
S
Klasy
biznesowe
Klasy
dostę pu do
danych
Klasy
biznesowe
Baza danych
Warstwa
trwałości z
deskryptorami
odwzorowań
S
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
7
format XML. Narzę dzia komercyjne, takie jak TopLink oferują wygodne edytory odwzorowań
(Mapping WorkBench).
P
P
r
r
o
o
j
j
e
e
k
k
t
t
o
o
w
w
a
a
n
n
i
i
e
e
w
w
a
a
r
r
s
s
t
t
w
w
y
y
t
t
r
r
w
w
a
a
ł
ł
o
o
ś
ś
c
c
i
i
S
S
A
A
M
M
O
O
D
D
Z
Z
I
I
E
E
L
L
N
N
E
E
T
T
W
W
O
O
R
R
Z
Z
E
E
N
N
I
I
E
E
W
W
A
A
R
R
S
S
T
T
W
W
Y
Y
A
A
Z
Z
A
A
K
K
U
U
P
P
Zbudowanie dobrej warstwy trwałości jest trudnym zadaniem. Niemniej trudne jest jej
pielę gnowanie. Ponieważ ma ona stanowić tylko oprogramowanie narzę dziowe, zwykle nie bę dzie
tak rozwinię ta jak produkty komercyjne. Ponadto samodzielne stworzenie warstwy stanowi pewne
ryzyko. Biorąc to wszystko pod uwagę warto sprawdzić , czy nie dałoby się kupić narzę dzia do
tworzenia warstwy trwałości. Na rynku jest dość dużo tego typu produktó w działających w ję zyku
Java, np.:
•
VBSF (Object Matter),
•
Blend (Sun Microsystems),
•
TopLink (WebGain),
oraz produkty public domain, jak np.:
•
Osage,
•
Castor.
Warto jednak najpierw zorientować się , czego oczekujemy od warstwy.
W
W
Y
Y
M
M
A
A
G
G
A
A
N
N
I
I
A
A
Przed przystąpieniem do projektu należ y określić potrzeby, któ re ma spełniać warstwa trwałości.
Oczywiście waż ne jest, żeby projekt nie przekraczał możliwości zespołu, budżetu itd. Wymagania
powinny być na tyle duże, żeby zaspokajać oczekiwania użytkownikó w warstwy, ale na tyle małe,
żeby twó rcy byli w stanie ją dostarczyć w wyznaczonym czasie. Ró ż ne typy aplikacji stawiają inne
wymagania warstwie trwałości. Dla aplikacji związanych z prowadzeniem przedsię biorstwa waż na
bę dzie łatwość wprowadzania zmian w warstwie dziedziny problemu, podczas gdy w przypadku
repozytorió w narzę dzi CASE istotniejsze bę dzie dobre rozwiązanie przetwarzania złożonych struktur
danych. Niektó re systemy muszą być tworzone z założeniem, że każ de wdroż enie moż e wymagać
użycia innej bazy danych, w innych przypadkach wiadomo, ż e bę dzie to jedna baza i nigdy się nie
zmieni. Dlatego też poniższa lista zawiera możliwie duż y zbió r wymagań, czę sto ze wskazó wkami,
kiedy mogą być istotne. W niektó rych przypadkach podany jest rodzaj wymagania z listą rozwiązań
do wyboru.
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
8
H
H
e
e
r
r
m
m
e
e
t
t
y
y
z
z
a
a
c
c
j
j
a
a
d
d
o
o
s
s
t
t
ę
ę
p
p
u
u
d
d
o
o
d
d
a
a
n
n
y
y
c
c
h
h
Podstawowym zadaniem warstwy trwałości jest ukrycie przed pozostałymi warstwami
szczegó łó w dotyczących dostę pu do danych. W zależności od stopnia złożoności
tworzonego oprogramowania wymagania związane z hermetyzacją dostę pu mogą być
ró żne.
a) W najprostszym przypadku hermetyzacja polega na tym, że użytkownik warstwy
wywołuje tylko metody obiektó w trwałych Retrieve, Save, Delete. Nie zna ani
położenia fizycznych danych, ani sposobu zapisu.
b) Bardziej ambitne rozwiązanie to hermetyzacja rozumiana jako przezroczystość.
Użytkownik takiej warstwy nie wie nawet, kiedy i czy w ogó le coś zapisuje, bądź
odczytuje. Oczywiście pełna przezroczystość jest nieosiągalna ze wzglę du na
wielodostę p (a wię c transakcje, blokowanie danych, odświeżanie), ale można
uzyskać dobre przybliżenie. W moim odczuciu wystarczającym przybliżeniem jest
przezroczystość algorytmiczna, w przypadku, któ rej w kodzie związanym z
dziedziną problemu pojawiają się pewne elementy dotyczące bazy danych, ale
nie wpływają na przebieg algorytmó w.
M
M
i
i
n
n
i
i
m
m
a
a
l
l
i
i
z
z
a
a
c
c
j
j
a
a
o
o
g
g
r
r
a
a
n
n
i
i
c
c
z
z
e
e
ń
ń
w
w
s
s
t
t
o
o
s
s
o
o
w
w
a
a
n
n
i
i
u
u
t
t
e
e
c
c
h
h
n
n
i
i
k
k
o
o
b
b
i
i
e
e
k
k
t
t
o
o
w
w
o
o
z
z
o
o
r
r
i
i
e
e
n
n
t
t
o
o
w
w
a
a
n
n
y
y
c
c
h
h
Oprogramowanie realizujące warstwę dostę pu do danych nie powinno zmuszać do
dostosowywania obiektó w biznesowych do potrzeb relacyjnej bazy danych, zwłaszcza,
jeśli chodzi o dziedziczenie i związki.
R
R
o
o
z
z
s
s
z
z
e
e
r
r
z
z
a
a
l
l
n
n
o
o
ś
ś
ć
ć
Warstwa trwałości powinna być tak skonstruowana, żeby łatwo było dodawać nowe klasy
do mechanizmu trwałości. Poziom rozszerzalności zależy w zasadzie od rodzaju warstwy
trwałości. W przypadku warstwy dostę pu z deskryptorami odwzorowań wystarczy dopisać
odpowiednie deskryptory.
F
F
o
o
r
r
m
m
u
u
ł
ł
o
o
w
w
a
a
n
n
i
i
e
e
z
z
a
a
p
p
y
y
t
t
a
a
ń
ń
Warstwa powinna umożliwiać zadawanie pytań, i to nie bezpośrednio w SQL, tylko w
kategoriach obiektó w. W zależności od tworzonego systemu mogą być potrzebne proste
zapytania o wartości atrybutó w, albo bardzo złożone z odwołaniem do obiektó w
powiązanych, z operatorami sprawdzania, czy element należy do kolekcji itd. W
ekstremalnym przypadku może wystąpić potrzeba zaimplementowania OQL. Dobrze
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
9
byłoby uwzglę dnić możliwość formułowania podzapytań na kolekcjach, zwłaszcza na
rolach.
Głó wna trudność polega jednak na tym, ż e trzeba wprowadzić mechanizm
przeszukiwania pod kątem zapytania obiektó w znajdujących się w pamię ci operacyjnej.
W
W
s
s
p
p
a
a
r
r
c
c
i
i
e
e
d
d
l
l
a
a
c
c
z
z
ę
ę
ś
ś
c
c
i
i
o
o
w
w
e
e
g
g
o
o
o
o
d
d
c
c
z
z
y
y
t
t
u
u
Dość czę sto się zdarza, że nie chcemy odczytywać wszystkich atrybutó w obiektu, a tylko
takie, któ re mają być w danym momencie wyświetlone. W przypadku duż ych zapytań
taki czę ściowy odczyt moż e dać duży zysk czasowy i zmniejszyć zapotrzebowanie na
pamię ć .
M
M
e
e
c
c
h
h
a
a
n
n
i
i
z
z
m
m
y
y
o
o
p
p
ó
ó
ź
ź
n
n
i
i
o
o
n
n
e
e
g
g
o
o
o
o
d
d
c
c
z
z
y
y
t
t
u
u
Podczas odczytywania obiektu trwałego odczytywanie obiektó w powiązanych z nim
powinno być opcjonalne. Żeby można było odczytać je pó źniej trzeba znaleźć jakiś
sposó b na reprezentowanie ró l.
M
M
e
e
c
c
h
h
a
a
n
n
i
i
z
z
m
m
y
y
o
o
p
p
ó
ó
ź
ź
n
n
i
i
o
o
n
n
e
e
g
g
o
o
z
z
a
a
p
p
i
i
s
s
u
u
W przypadku, gdy obiekty trwałe są zapisywane jawnie, przez wywołanie metody Save,
algorytmy w warstwie biznesowej zależą od kolejności zapisu. Aby zapobiec tego
rodzaju wpływowi należy zapisywać obiekty trwałe w jednym kroku.
R
R
ó
ó
ż
ż
n
n
e
e
m
m
e
e
c
c
h
h
a
a
n
n
i
i
z
z
m
m
y
y
t
t
r
r
w
w
a
a
ł
ł
o
o
ś
ś
c
c
i
i
W pewnych sytuacjach moż e zachodzić potrzeba zapisywania obiektó w trwałych w
bardzo ró żnorodny sposó b. Nie tylko w bazach relacyjnych, ale w obiektowo-
relacyjnych, obiektowych, w plikach tekstowych, plikach ISAM lub VSAM itd.
B
B
a
a
z
z
y
y
d
d
a
a
n
n
y
y
c
c
h
h
o
o
d
d
r
r
ó
ó
ż
ż
n
n
y
y
c
c
h
h
d
d
o
o
s
s
t
t
a
a
w
w
c
c
ó
ó
w
w
Ró żne bazy relacyjne stosują ró żne dialekty SQL. Bardzo czę sto konstrukcje w jednej
bazie optymalne, w innej są bardzo nieefektywne. Jeśli tworzony system ma działać
skutecznie z ró żnymi bazami danych, trzeba to uwzglę dnić odpowiednio wcześnie.
Projektowanie warstwy dostę pu do bazy danych. Warstwa trwałości.
Copyright
2001 - 2002 POTIS Software Development Tools
10
P
P
o
o
ł
ł
ą
ą
c
c
z
z
e
e
n
n
i
i
a
a
z
z
w
w
i
i
e
e
l
l
o
o
m
m
a
a
b
b
a
a
z
z
a
a
m
m
i
i
d
d
a
a
n
n
y
y
c
c
h
h
w
w
j
j
e
e
d
d
n
n
e
e
j
j
s
s
e
e
s
s
j
j
i
i
Wię kszość organizacji posiada wię cej niż jedną bazę danych, bardzo czę sto poszczegó lne
bazy danych są od ró żnych dostawcó w. Dobra warstwa trwałości powinna umożliwiać
obsługiwanie wielu połączeń na raz.
L
L
i
i
t
t
e
e
r
r
a
a
t
t
u
u
r
r
a
a
•
Jacobson I, Object Oriented Software Engineering, A Use Case Driven Approach, Addison-
Wesley 1994.
•
Ambler S.W, The Design of a Robust Persistence Layer For Relational Databases,
http://www.AmbySoft.com/persistenceLayer.pdf
.
•
Keller W, Object-Relational Access Layers,
http://ourworld.compuserve.com/homepages/WolfgangWKeller
.