Bliskie związki z bazą danych

Sybase DataWindow .Net to rozbudowany obiekt do wyświetlania danych w aplikacjach klienckich, pozwalający łatwo synchronizować lokalne dane z serwerem, ale bez kłopotów związanych z kursorami.

Sybase DataWindow .Net to rozbudowany obiekt do wyświetlania danych w aplikacjach klienckich, pozwalający łatwo synchronizować lokalne dane z serwerem, ale bez kłopotów związanych z kursorami.

Projektując środowisko .Net, Microsoft zdecydował się na dosyć radykalne decyzje architektoniczne narzucające określoną strukturę aplikacji pracującej z danymi. Każda operacja na bazie danych składa się z trzech etapów: połączenie z bazą, wysłanie polecenia/odebranie wyników oraz odłączenie od bazy. Takie podejście gwarantuje wysoką skalowalność systemu, ale równocześnie sprawia, że aplikacja musi "tymczasowo" przechować porcję danych w jakimś "pojemniku" (np. DataSet).

Oderwani od bazy

Takie podejście w naturalny sposób izoluje rozwiązanie od konkretnej bazy danych - aplikacja opiera się na tym, czym dysponuje pojemnik przechowujący dane np. w DataSet, przy czym DataSet może być pobrany z usługi Web, a niekoniecznie wypełniony danymi z bazy. W przypadku nowoczesnych aplikacji typu SmartClient wykorzystanie tymczasowego "pojemnika" po stronie klienta pozwala założyć, że połączenie z zapleczem serwerowym nie jest stale dostępne. Łatwo też można system dostosować do pracy w trybie offline.

Przyjęcie takiej architektury utrudnia stworzenie "klasycznego" interfejsu klienckiego, w którym siatka wyświetlająca dane "wisi" bezpośrednio na jakiejś tabeli, widoku czy wyrażeniu . Czasy, gdy formatka klienta automatycznie pokazuje to co uległo zmianie po stronie serwera oraz pozwala edytować czy dodawać dane bezpośrednio na serwerze, odchodzą do historii.

Ale jeszcze nie całkiem. Taka funkcjonalność wciąż jest dostępna np. w narzędziach FoxPro, PowerBuilder, a także w starych wersjach bibliotek ADO i RDO. Zarzucenie tego podejścia wiąże się z odejściem od , czyli oddzielnych kopii danych dla każdego klienta przechowywanych po stronie serwera.

Pisanie aplikacji w taki sposób sprawia, że są one bardzo ściśle związane z konkretnym serwerem bazodanowym i trudno jest migrować do serwera innego producenta. Do tego przeniesienie rozwiązania np. w tryb offline jest raczej niemożliwe.

No i powstaje niezbyt eleganckie rozwiązanie, w którym bezpośrednio z interfejsu użytkownika aplikacja wykonuje operacje bazodanowe.

W konsekwencji wszelkie zmiany struktury bazy wymagają dostosowania warstwy klienckiej.

Sięganie do źródła

Mimo tych problemów nadal zdarza się, że klienci oczekują, że aplikacja będzie mieć np. zawsze aktualną, pełną listę faktur i "coś" sobie wyfiltruje. Dodatkowo, czasami 90% systemu to tak naprawdę proste formatki bazodanowe, gdzie niemal od razu wprowadza się dane do tabel bezpośrednio w bazie. Właśnie do takich scenariuszy przeznaczony jest jeden z mniej znanych produktów Sybase - DataWindow .Net. Jest to uniwersalna "kontrolka siatki", przeznaczona do pracy bezpośrednio na źródle w bazie danych. Może być użyta zarówno w ASP .Net, jak i w normalnych aplikacjach Windows Forms.

Sposób użycia DataWindow .Net różni się nieco od tego, co można zrobić ze standardowymi kontrolkami w .Net. W pierwszym etapie tworzona jest specjalna biblioteka zawierająca definicję układu i źródła danych, które zostaną pokazane w kontrolce. Można wybrać jeden z 10 "wzorców podstawowych". Może to być np. free form, gdzie dowolnie rozkładamy informacje na formatce, albo "klasyczna" siatka przypominająca arkusz Excela. Równie dobrze może to być tabela przestawna z dynamicznie generowanymi wierszami i kolumnami. Ciekawym typem jest też widok "drzewa" pozwalający zdefiniować hierarchię oraz określić, które elementy mogą być edytowane.

Następnie definiowane jest "źródło" danych. W ramach bibliotek definiowane są różne połączenia do konkretnych bazodanowych. Sybase DataWindow .Net 2.0 może współpracować niemal z dowolną bazą danych. Obsługuje sterowniki ODBC/OLE DB .Net, ale w takim przypadku nie obsługuje "pełnych" mechanizmów danej bazy danych.

Na przykład nie można użyć kolumn z długimi liczbami czy danych typu XML w formacie SQL Server 2005. Natomiast ma także rozbudowane "własne" sterowniki, m.in. dla Informix v9 i wyższych, Oracle 8/9/10 oraz oczywiście dla baz Sybase. Jedyna baza, która nie jest obsługiwana "prosto z pudełka", to DB2.

Lokalna logika

Definiując źródło danych, tworzony jest specjalny "profil", który potem może być użyty przy konstrukcji "połączenia" dla danego okna DataWindow. Samo źródło może być określone na kilka sposobów. Może to być dowolne wyrażenie SQL, procedura przechowywana, wskazana kwerenda zapisana w bibliotece. W takiej kwerendzie można np. zawrzeć standardowy opis poszczególnych pól, co potem zostanie użyte przy generowaniu początkowego interfejsu.

Dla Sybase DataWindow dostępny jest kreator, który pozwala wskazać początkową tabelę, a potem, zgodnie z odczytanymi informacjami o związkach w relacyjnej strukturze tabeli, można np. dodać powiązany element, wskazać go jako członka relacji master-detail itp.

Alternatywnie można tylko podać listę pól. W DataWindow .Net 2.0 można też użyć DataSet z ADO .Net, choć akurat ten sposób przekazywania danych do DataWindow nie jest najwygodniejszy. Aktualizacja wymaga określenia tego, które kolumny stanowią klucz główny, a które można modyfikować. Można także założyć, że zamiast bezpośredniej aktualizacji wywoływane będą procedury przechowywane, wykonujące operacje na danej bazie.

W ten sposób jedno wyrażenie służy do wypełnienia i pokazania danych w DataWindow, natomiast aktualizacja jest realizowana równolegle, całkiem niezależnie. Z punktu widzenia kodu zapisanie zmian to wykonanie jednej metody - Update(). Przełączając jedną właściwość można definiować, czy sortowanie/filtrowanie będzie wykonane na lokalnie pobranej porcji danych, czy na serwerze.

Wygoda i elastyczność

Projektowanie interfejsu DataWindow niewiele różni się od tworzenia normalnych formatek - mamy pasek z właściwościami itp. Zawsze jednak można "podejrzeć" dane, a nawet przetestować całą siatkę. Z ciekawszych rzeczy warto wspomnieć o mechanizmie "DropDownDataWindow", który pozwala, by dane słownikowe osadzone były na siatce.

W ten sposób można bez kodowania pozwolić użytkownikowi wybrać odpowiednią wartość albo by wygodnie uzupełnił słownik, mimo że jest w trakcie dodawania innego rekordu.

Sama definicja wyglądu to dokument tekstowy, ale nie w formacie XML. Zamiast klikać w projektancie, można więc ręcznie zmienić odpowiednie wpisy. Natomiast w XML można zapisać standardowy "wygląd" elementów, by potem taki wzorzec wczytać przy projektowaniu nowego okna. Użycie DataWindow z poziomu kodu .Net sprowadza się w zasadzie do dwóch czynności - przeciągnięcia na formatkę odpowiedniej kontrolki i wskazania we właściwościach z jakiej biblioteki mają być pobierane metadane źródła danych i układu elementów.

W przypadku gdy informacje mają być pokazane za pośrednictwem witryny ASP .Net, możemy określić, w jaki sposób dane będą renderowane i przesyłane do przeglądarki. Może to być XML + XSLT (układ/transformacje) z plikiem CSS określającym styl. Może to być dokument XHTML albo HTML. Kontrolka kliencka Web DataWindow to kod JavaScript + odpowiedni sposób prezentacji. Część prostych walidacji jest wykonywana po stronie klienta (przeglądarki), ale duża część operacji powoduje po prostu wysłanie odpowiedniego żądania do serwera. Niestety synchronicznie, co powoduje, że użytkownik czeka na odświeżenie strony.

Ciężkie, bo użyteczne

Podsumowując, Sybase DataWindow .Net nie jest "lekką" kontrolką - duża część informacji będzie przetwarzana po stronie serwera i często będą przesyłane informacje do komputera klienckiego. W analogiczny sposób Sybase pozwala uruchamiać rozwiązania używające PowerBuilder za pośrednictwem specjalnego serwera aplikacyjnego i migrować rozwiązania klient-serwer, by można z nich było korzystać przez przeglądarkę WWW.

Na koniec wypada "ostrzec", że nie należy oczekiwać bardzo atrakcyjnego wyglądu interfejsu generowanego przez DataWindow .Net. Ostateczny rezultat wygląda trochę "siermiężnie", zwłaszcza gdy porówna się wygląd z np. DevExpress XtraGrid. Korzyść z zastosowania rozwiązania Sybase polega jednak na tym, że pozwala ono zaprojektować "obiekt" opisujący jak dane mają być prezentowane i edytowane, a następnie po prostu przypisuje taką definicję do kontrolki - czy to umieszczonej w aplikacji Windows Forms, czy na stronie ASP .Net 2.0. Tego nie oferują inne rozwiązania.

Sposób na "gadatliwość"

Kontrolka Sybase DataWindow to rozwiązanie dość "gadatliwe" sieciowo. Jeżeli w programie mają być wykonane jakieś operacje na danych, można użyć obiektu DataStore. Zachowuje się on jak DataWindow, ale nie pokazuje żadnych danych użytkownikowi. Może pobrać dane do lokalnego pojemnika i pozwolić, by były one programowo przetworzone, a dopiero później udostępnione itp. W prosty sposób można także określić, że operacje mają być wykonywane w ramach transakcji.

W tym celu na formatkę należy przeciągnąć obiekt Transaction, po czym wskazać, że obiektu tego ma używać np. DataWindowControl.

DataWindow, jedyne w swoim rodzaju

Nie tylko Sybase próbuje umożliwić łatwe, ale i bezpieczne tworzenie interfejsów typu siatka, silnie związanych z bazą danych pomimo ograniczeń .Net w tym względzie. Żadna inna firma nie oferuje jednak niemal całkowicie własnej warstwy dostępowej - analogiczny efekt uzyskiwany jest zwykle przy użyciu zupełnie innych metod. Na przykład ComponentOne LLC ma w ofercie C1DataObjects - mechanizm, który w trybie virtual mode pozwala po stronie klienta utrzymywać "duży" DataSet pobierający asynchronicznie dane z serwera. To rozwiązanie można także stosować w architekturze trójwarstwowej. Można nawet osiągnąć taki efekt, że po stronie serwera aplikacyjnego stoi komponent, który fizycznie pobiera dane, a siatka, w momencie gdy np. użytkownik grupuje czy filtruje informacje, wysyła polecenia do takiego komponentu, otrzymując zwrotnie odpowiednią porcję danych. W ten sposób użytkownik ma wrażenie, że widzi wszystkie dane, ale w rzeczywistości przesyłane jest tylko to co niezbędne.


TOP 200