22.Rozdziaę 21.pdf
(
224 KB
)
Pobierz
33672166 UNPDF
Rozdział 21
Reguły logiki aplikacji w aplikacjach
Delphi
W rozdziale tym omawiamy aplikacyjną stronę udanej implementacji reguł logiki
aplikacji. Jak to już powiedziałem wrozdziale oregułach logiki aplikacji
bazujących na serwerze, w moim głębokim przekonaniu reguły te powinny być -
jeśli to tylko możliwe - implementowane po serwerowej stronie aplikacji. Jednak
w realnych aplikacjach nieuniknione będzie uzupełnianie reguł logiki aplikacji
zrealizowanych po stronie serwera regułami osadzonymi w oprogramowaniu
pośredniczącym lub klienta. Chciałbym wierzyć, że pewnego dnia między
serwerami baz danych, produktami middleware i narzędziami do tworzenia
oprogramowania zaistnieje taki synergizm, iż problem ten zniknie całkowicie
i programista przestanie zajmować się tym,
gdzie
jego reguły są
zaimplementowane, a skoncentruje się na tym,
jak
są one zaimplementowane.
Wśród programistów z długim stażem występuje skłonność do umieszczania
znacznej części reguł logiki aplikacji wsamej aplikacji. Świat narzędzi
programistycznych jest dla nich terytorium już „oswojonym”, natomiast
platformom DBMS tradycyjnie brakowało owych wyszukanych narzędzi do
wdrażania reguł logiki aplikacji, bez których aplikacje na wysokim poziomie nie
mogą się obejść.
Abstrahując jednak od wszelkich skłonności, przeniesienie reguł logiki aplikacji
hurtem do niej samej nie jest - jak już powiedziałem - żadnym rozwiązaniem.
Środowisko programistów powinno zmusić producentów DBMS i oprogramo-
wania pośredniczącego do stworzenia wszechstronnych interfejsów dla reguł
logiki aplikacji - czyli takich interfejsów, jakich potrzebują profesjonalne
aplikacje. Odpowiedzią nie może być zwykle „machnięcie ręką” i wyproduko-
wanie banalnego rozwiązania, bazującego na pośledniej technologii. Najlepszym
podejściem byłoby skłonienie producentów do tego, by wyszli na przeciw
potrzebom swych klientów - by dostarczyli takiego wsparcia reguł logiki aplikacji,
jakiego użyć można w prawdziwych aplikacjach. Zanim to nie nastąpi, systemy
klient/serwer będą nadal równie nieodporne na naruszenia reguł logiki aplikacji, co
ich niegdysiejsi plikowi odpowiednicy.
Ku chwale producentów DBMS i oprogramowania pośredniczącego przyznać
trzeba jednak, że w korygowaniu swych strategii reguł logiki aplikacji poczynili
ostatnio spore postępy. W przeszłości większość implementacji reguł logiki
628
Część IV
aplikacji bazujących na serwerze charakteryzowała się całkowitą „hermetycz-
nością” - były bezpieczne - lecz dla programisty „nieprzyjazne”. Programiści mieli
na przykład problemy ze skłonieniem obiektów bazy danych i obiektów aplikacji
do bezkonfliktowej współpracy. Jeśli na przykład jako źródło wartości dla
wstawianego wiersza użyty został domyślny obiekt Sybase, to skąd aplikacja
mogłaby o tym wiedzieć i w jaki sposób miałaby wyświetlić na ekranie domyślne
wartości kolumn, gdyby użytkownik dodał nowy wiersz do tabeli? Programiście
pozostawał tylko wybór mniejszego zła - albo całkowite ignorowanie bazujących
na serwerze reguł logiki aplikacji i ponowne implementowanie ich w aplikacjach,
albo rezygnacja zsynchronizowania widoku aplikacji na ekranie zjej
bazodanowymi partnerami. Żadna ztych możliwości nie była szczególnie
pociągająca i, jak zauważył kiedyś Jerry Garcia, „wybieranie mniejszego zła jest
także wybieraniem zła”.
Na szczęście wostatnich czasach producenci DBMS ioprogramowania
pośredniczącego stają się coraz bardziej przyjaźni wobec użytkowników.
Rozsądne projektowanie reguł logiki aplikacji stało się obecnie łatwiejsze niż
kiedykolwiek. Jednocześnie narzędzia do projektowania aplikacji baz danych,
takie jak Delphi, stają się coraz bardziej świadome istnienia swych
„współrozmówców” w bazach danych i oprogramowaniu pośredniczącym i coraz
więcej onich wiedzą. Wrezultacie narzędzia programistyczne iprodukty
serwerowe zaczynają jednoczyć się w dążeniu do zaspokojenia potrzeb ludzi
W miarę, jak platformy DBMS, produkty middleware i narzędzia programistyczne
będą się uczyć ze sobą współpracować, implementowanie rozsądnej strategii reguł
logiki aplikacji będzie coraz łatwiejsze.
Jednak niezależnie od tego, w którą stronę zmierza postęp, na razie musimy
borykać się z tym, co dostępne jest tu i teraz. Aktualna sytuacja jest zaś taka, że
najprawdopodobniej będziemy musieli zaimplementować część reguł logiki
aplikacji w samej aplikacji. Jak już powiedziałem w rozdziale o regułach po
stronie serwera, podejście, jakie ja zwykle przyjmuję, jest następujące: na
platformie DBMS implementuję całą tę strategię reguł logiki aplikacji, którą mogę
tam zaimplementować, a potem w miarę potrzeby uzupełniam ją
w oprogramowaniu pośredniczącym (middleware) lub na kliencie. I nie ma tu
znaczenia, czy mamy do czynienia ztabelami bazy Paradox, czy też
najprawdziwszą implementacją klient/serwer. To, czego nie mogę zaimplemento-
wać na serwerze, implementuję w middleware i w kliencie. Innymi słowy, tymi
konstrukcjami wypełniam luki w implementacji bazującej na serwerze.
Rozdział ten zajmuje się aplikacyjną stroną prawidłowej implementacji reguł
logiki aplikacji. Dokonuje przeglądu różnych sposobów planowania efektywnej
strategii reguł logiki aplikacji w naszym programie. Dowiemy się w nim na
przykład, że w Delphi są cztery główne poziomy projektowania bazujących na
oprogramowaniu reguł logiki aplikacji: poziom typu danych, poziom
Rozdział 21 Reguły logiki aplikacji w aplikacjach Delphi
629
komponentów, poziom
TField
i poziom
TDataSet
. Każdy z nich omówię
szczegółowo, dzięki czemu Czytelnik bez trudu zrozumie, jak je stosować we
własnych aplikacjach.
Typy reguł logiki aplikacji
Reguły logiki aplikacji dzielą się na dwa wyraźnie odmienne typy:
proste
reguły
logiki aplikacji i
złożone
reguły logiki aplikacji. Proste zapewniają prostą
integralność encji. Gwarantują one na przykład, że dane liczbowe trafią do pola
liczbowego, kolumna dat zawierać będzie tylko daty i tak dalej. Proste reguły mają
zastosowanie niezależnie od tego, czym dana aplikacja jest lub do czego baza
danych jest używana.
Reguły złożone dotyczą bardziej zaawansowanych aspektów dostępu do bazy
danych - pozwalają one zapewnić integralność referencyjną. Zwykle są przy tym
specyficzne dla danej bazy danych lub nawet konkretnej tabeli.
W książce tej terminu
reguły logiki aplikacji
używam w jego najszerszym sensie.
Innymi słowy wszystko, o czym mówię, dotyczy zarówno reguł prostych, jak
i złożonych. Wszystko, począwszy od prostego sprawdzenia poprawności danych,
a na skomplikowanej integralności relacyjnej skończywszy, zmieści się pod
„parasolem” reguł logiki aplikacji. Chociaż z generalnego omówienia reguł logiki
aplikacji mógłbym wyłączyć techniki sprawdzania poprawności danych, to nie
widzę żadnych korzyści z takiego rozwiązania. Metody stosowane
w implementacji prostych reguł logiki aplikacji są takie same, jak metody używane
do tworzenia reguł złożonych. Dlatego moje podejście polega na omówieniu
efektywnego projektowania reguł logiki aplikacji zperspektywy ogólnej.
Niezależnie od tego, czy są to reguły proste, czy złożone, wszystkie one zasługują
na jednakową uwagę.
Delphi dostarcza kilku sposobów konstruowania prostych reguł logiki aplikacji bez
żadnego kodowania i oferuje zgrabny komplet narzędzi do konstruowania reguł
złożonych z użyciem minimalnej ilości kodu. W rozdziale tym przeanalizujemy,
z perspektywy aplikacji, oba typy reguł.
Dwie zasady dla reguł logiki aplikacji
Pierwszym poziomem implementacji reguł logiki aplikacji po stronie klienta jest
poziom typu danych. Trzeba mieć zawsze na uwadze dwie podstawowe zasady
ilustrujące dobitnie doniosłość właściwego wyboru typu danych. Jeśli będziemy
ich przestrzegać, to zawczasu unikniemy wielu typowych problemów, jakie
niekiedy gnębią mniej doświadczonych programistów.
630
Część IV
Zasada pierwsza
Pierwsza zasada ustanawiania reguł logiki aplikacji po stronie klienta brzmi:
Przede wszystkim używaj odpowiednich typów danych spośród dostępnych
w bazie.
VCL w Delphi narzuca kilka prostych, wbudowanych ograniczeń zależnych od
typu danych, jakie kolumna reprezentuje. Na przykład komponenty skojarzone
z danymi (data-aware) nie będą tolerować niepoprawnych dat w kolumnach o typie
„data”, znaków alfabetycznych w polach liczbowych, lub niewłaściwych wartości
w polach logicznych. By narzucić te ograniczenia, nie musimy tworzyć żadnego
kodu - Delphi zrobi to automatycznie. Po prostu trzeba od samego początku
używać odpowiednich typów danych.
Wśród programistów-weteranów zauważa się skłonność do nadużywania typów
łańcuchowych przy tworzeniu baz danych. Widziałem na przykład tabele
zawierające kolumny z datami, które były zdefiniowane z pomocą łańcuchowych
typów danych. Widziałem także dane liczbowe przechowywane wpolach
znakowych. Jeśli kolumna ma zawierać daty i tylko daty, to zdefiniujmy ją
korzystając z jakiegoś typu daty. Jeśli pole może zawierać tylko liczby, to
zdefiniujmy je przy pomocy numerycznego typu danych. Nie ma powodu, by
wartości numeryczne trzymać w kolumnach alfabetycznych.
Inna sytuacja, w której używanie właściwych typów danych ma dla poprawnego
projektowania reguł logiki aplikacji zasadnicze znaczenie, związana jest
z kolumnami zawierającymi wartości sekwencyjne. Choć niewątpliwie
moglibyśmy stworzyć system numerowania sekwencyjnego w kodzie Object
Pascal, to najlepiej będzie od razu użyć typów danych, które z samej swej natury
są sekwencyjne. Na przykład Sybase i Microsoft wspierają stosowanie
kolumn
indentyfikacyjnych
(
identity columns
) - specjalnych kolumn, automatycznie
inkrementowanych przez serwer. Korzystając z autoinkrementowanych typów
danych unikamy konieczności samodzielnego generowania liczb sekwencyjnych
i zapewniamy sobie, że podstawowa reguła logiki aplikacji, o która nam chodzi -
liczby w kolumnie Y tablicy X muszą być sekwencyjne
- zostanie zrealizowana
praktycznie bez żadnego wysiłku z naszej strony.
Zasada druga
Druga podstawowa zasada obowiązująca przy implementowaniu bazujących na
aplikacji reguł logiki aplikacji brzmi:
Używaj takich komponentów Delphi, które najlepiej odpowiadają bazowym typom
danych.
Rozdział 21 Reguły logiki aplikacji w aplikacjach Delphi
631
Błędem, który w tej dziedzinie programiści robią najczęściej, jest zbyt szerokie
stosowanie komponentów do wprowadzania normalnego tekstu. Tego rodzaju
komponenty (takie jak
DBEdit
,
TEdit
i
TMaskEdit
) mogą umożliwić
wpisanie w pole wartości nieodpowiednich dla typu danej, z jaką komponent jest
skojarzony. Unikamy tego używając wpierwszym rzędzie odpowiednich
komponentów.
Na przykład nie powinniśmy używać
DBEdit
dla pól logicznych. Pole to może
mieć tylko dwie wartości:
True
i
False
. Dlatego zamiast pola edycyjnego
użyjmy przycisku przełącznika (
checkbox
), przycisku opcji (radio button) lub listy
rozwijanej (
drop-down list
). Nie używajmy także
DBEdit
dla pól, których
wartości są tylko do odczytu; zamiast niego użyjmy komponentu DBText. Chroni
to zasoby systemowe i oszczędza kłopotu z ustawianiem właściwości
ReadOnly
komponentu. Podobnie
DBEdit
nie powinniśmy używać dla kolumn liczbowych,
które mogą mieć tylko niewielką ilość dopuszczalnych wartości - tutaj lepszy
będzie
DBRadioGroup
. Tabela 21.1 podaje, których komponentów najlepiej
używać z rozmaitymi podstawowymi typami danych.
Tabela 21.1. Typy danych w kolumnach i odpowiadające im komponenty VCL
Typ danych
Komponenty
Boolowski
DBCheckBox
,
DBRadioGroup
,
DBComboBox
,
DBListBox
Data
DBEdit
,
Calendar
,
SpinEdit
,
DataTimePicker
Liczbowy (pozwalający na
wprowadzanie dużych ilości wartości)
DBEdit
,
SpinEdit
Liczbowy (pozwalający na
wprowadzenie jedynie niewielkiej ilość
wartości)
DBRadioGroup
Łańcuch (pozwalający na wprowadzanie
dużych ilości wartości)
DBEdit
Łańcuch (pozwalający na wprowadzanie
jedynie niewielkiej ilości wartości)
DBComboBox, DBListBox
Plik z chomika:
damians63
Inne pliki z tego folderu:
Apress MATLAB Differential and Integral Calculus (2014).pdf
(5153 KB)
Scientific Computing with Matlab and Octave - Alfio Quarteroni & Fausto Saleri.pdf
(7557 KB)
Roman Trobec, Marián Vajteric, Peter Zinterhof-Parallel Computing_ Numerics, Applications, and Trends-Springer (2009).pdf
(1531 KB)
Robert Paige, J.H. Reif, Ralph Wachter-Parallel Algorithm Derivation and Program Transformation-Springer (1993).pdf
(13174 KB)
Oded Goldreich-Computational Complexity_ A Conceptual Perspective (2008).pdf
(4861 KB)
Inne foldery tego chomika:
▬µTorrent▬
▬Android▬
▬Audiobooki▬
▬Gry PC▬
▬Minecraft▬
Zgłoś jeśli
naruszono regulamin