System operacyjny Longhorn, a dokładnie Visual Studio w wersji Whidbey, wprowadzi wiele udogodnień, a także kilka całkiem nowych mechanizmów pracy z danymi.

Wraz z systemem operacyjnym Longhorn Microsoft zamierza wprowadzić wiele nowych mechanizmów i udogodnień w komponentach i narzędziach odpowiedzialnych za dostęp do danych. Oprócz obsługi wszystkich nowych technologii Longhorn, Whidbey - kolejne wcielenie pakietu Visual Studio .Net - będzie oferować programistom jeszcze więcej ułatwień niż dotychczas.

Dane w pięć minut

W nowym ADO .Net zostaną uproszczone często wykonywane operacje. Przykładowo, standardowo będą dostępne obiekty wykorzystujące procesy działające w tle do pobierania danych z bazy. Dzięki temu kontrolki prezentujące dane, np. siatki, nie będą musiały długo oczekiwać na ich wyświetlenie, a użytkownik rzadko ujrzy na ekranie klepsydrę. W ADO .Net pojawi się specjalny komponent - DataContainer samodzielnie wykonujący dużą część operacji na danych.

Zaprezentowanie danych w siatce, i to od razu z możliwością ich sortowania, filtrowania czy stronicowania wyników, będzie się sprowadzać do napisania jednej linii kodu. Interesujące, że DataContainer może też być używany w warstwie logiki biznesowej.

Mechanizm kojarzenia interfejsu z danymi (binding) zostanie znacznie rozbudowany. Nadchodzące ADO .Net umożliwi wiązanie interfejsu bezpośrednio ze zdalnymi usługami, w tym oczywiście z usługami sieciowymi. Interfejsy narzędzi RAD zostaną przebudowane w taki sposób, aby jeszcze bardziej upraszczać kojarzenie elementów interfejsu z danymi, niż można to uczynić w Visual Studio .Net 2003.

Zmieni się także mechanizm aktualizacji danych w bazie. W przypadku wykorzystywania komponentu DataAdapter w .Net 1.1 do bazy jest wysyłany oddzielnie każdy zmieniony wiersz. W Whidbey operacje takie będą grupowane w formie "zadania wsadowego". W przypadku baz SQL Server i Oracle do wykonania takiej operacji wystarczy zadeklarowanie funkcji ze wskazaniem zakresu danych.

Tabelki w wielu smakach

W .Net 1.1 przekazywanie DataSet mechanizmem .Net Remoting działa mało efektywnie. W Whidbey zawartość DataSet może być przy tym przesyłana przy użyciu protokołów binarnych. Dzięki temu, wprawdzie kosztem "otwartości" standardów, ale jednak, otrzymujemy wydajny i szybki sposób zapisu, przesłania i odzyskania DataSet.

W nowym modelu DataSet DataTable (tabela) jest niemal samodzielnym obiektem. Microsoft wprowadził np. specjalny DataTableReader, który pozwala po kolei odczytywać wiersze tabeli w taki sposób, jakby to był obiekt uruchomiony na serwerze bazodanowym. W DataTable można też zdefiniować widok, który pokaże tylko unikalne wiersze. Zmieniono także tzw. maszynę indeksującą - przyspieszono zwłaszcza operacje dodawania do tabeli nowych elementów.

W Whidbey pojawi się zupełnie nowe API pozwalające w prosty sposób "przeglądać" olbrzymie zbiory danych metodą "strona po stronie". Metoda ExecutePageReader nie gwarantuje wprawdzie spójności transakcyjnej danych przy poruszaniu się pomiędzy stronami, ale za to działa znacznie szybciej niż stosowana do tej pory metoda pomijania niektórych wierszy. W nowej bibliotece ADO .Net znacznie uproszczono równoległe iterowanie po różnych zbiorach wynikowych w ramach transakcji. Mechanizm ten jest obsługiwany przez bazę danych Yukon - w ramach jednego połączenia można wykonać kilka równoległych żądań.

ObjectSpaces na dokładkę

W Whidbey ma się pojawić dodatkowy mechanizm dostępu do danych - tzw. ObjectSpaces. Jego początki sięgają jeszcze czasów beta 1 .Net Framework, jednak w kolejnych wersjach Microsoft wycofał się z jego rozwoju. Teraz ObjectSpaces powraca jako mechanizm przeznaczony do łatwego zapisywania "obiektów biznesowych" (instancji klas) w bazie relacyjnej.

W odróżnieniu od innych rozwiązań tego typu, w bazie może być zapisany dowolny obiekt zgodny z CLR - czyli praktycznie każdy obiekt .Net Framework (nie jest konieczne, by np. obiekty dziedziczyły z jakiejś bazowej klasy). Równocześnie Microsoft proponuje specjalną wersję języka OPath, pozwalającą przeszukiwać tak zapisane struktury. ObjectSpaces oferują także mechanizm "utrwalania" obiektów. Jeżeli pomiędzy zapisywanymi obiektami istnieją jakieś związki, np. gdy jeden z nich przechowuje tablice danych zarządzanych przez inne, jest to również odwzorowywane. Innymi słowy, jedno odwołanie do API ObjectSpaces wystarczy, aby w sposób trwały zapisać w bazie złożony schemat obiektów.

Szczypta XML, nieco SQL

Dużo zmian wprowadzono w obsłudze XML. Po pierwsze, działająca w środowisku SQL Server 2000 usługa SQLXML jest w Whidbey pełnoprawnym "źródłem" danych dla programu .Net. Za jego pomocą można wykonywać wszystkie operacje na danych dostępne przy użyciu "relacyjnego" mechanizmu ADO .Net.

Z danymi w formacie XML można także powiązać kontrolki służące do prezentacji danych. I odwrotnie: dane można "wysłać" do SQLXML, i tym samym zaktualizować bazę. Oczywiście, większość tych operacji można wykonywać przy użyciu .Net 1.1 oraz SQLXML, jednak w Whidbey będzie to znacznie prostsze - SQLXML w Whidbey jest w pewnym sensie "protokołem" obudowanym odpowiednim API. Jeżeli XML jest używany jako pośrednik pomiędzy bazą a aplikacją, zasady mapowania pomiędzy światem relacyjnym a XML-owym są określane dokładnie w taki sam sposób, jak w przypadku ObjectSpaces. Tworząc XML View, można stosować zarówno kwerendy SQL, jak i XQuery.

W .Net 1.1 do pracy z dokumentem XML jest używany głównie interfejs XMLDocument. W Whidbey wprowadzono nową klasę - XPathDocument, integrującą cechy klasy XMLDocument, oraz funkcje przyspieszające wyszukiwanie danych, które w .Net Framework 1.1 były obsługiwane oddzielnie. Wyszukany element dokumentu XML można zmieniać, używając XPathEditor albo prostego narzędzia XMLWriter. W praktyce wszystko to działa tak jak XML-owa baza danych. Na podstawie dostępnej wersji Whidbey trudno jednak powiedzieć cokolwiek na temat wydajności tego rozwiązania.

Zapach wolności

Podsumowując, w kolejnej wersji bibliotek dostępowych Microsoft oferuje programiście klasyczny relacyjny dostęp do danych przy użyciu udoskonalonego ADO .Net, mechanizm obiektowy .Net Framework, a także dodatkowe mechanizmy ObjectSpaces. W zależności od potrzeby chwili programista wybiera metodę akurat najwygodniejszą.

Nie jest jednak tak, że poszczególne metody wzajemnie się wykluczają - wszystkie trzy sposoby pracy z danymi mogą być ze sobą łączone. Stworzenie mechanizmu przekazywania danych między np. XML a ObjectSpaces jest stosunkowo proste.