22.Rozdziaę 21.pdf

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:

Inne pliki z tego folderu:

Inne foldery tego chomika: