ADO+ jest próbą dostosowania interfejsu dostępu do danych do architektury zgodnej z koncepcją Microsoft .NET.

Technologia ADO (ActiveX Data Object) była pierwszą próbą Microsoftu zmierzającą do realizacji idei "uniwersalnego dostępu do danych". Przed dwoma laty firma zaproponowała wspólny interfejs programistyczny, niezależny od źródła danych. Wystarczyło, że dla danej bazy danych czy systemu plików dostępny był sterownik OLE DB, by można było korzystać z modelu obiektowego ADO, przeglądać "tabele" itp. Po dwóch latach okazało się, iż dostęp nie jest tak uniwersalny, jak to było w założeniach.

Problemy ze starym ADO

ADO sprawdza się jako interfejs obsługujący bazy relacyjne. Gorzej radzi sobie z informacjami hierarchicznymi. Powstał nawet specjalny tzw. provider (dostawca) MSShape, który określał składnię SQL do obsługi hierarchicznych zestawów danych. Nie zmienia to faktu, że z punktu widzenia osoby tworzącej kod programu posługiwanie się "tablicami" rekordów nie jest intuicyjne.

Inny problem pojawił się w związku z architekturą trójwarstwową czy nawet aplikacjami opartymi na ASP. Każde połączenie z bazą danych wymaga wykorzystania pewnych zasobów serwera, a przy dużej liczbie klientów połączenie powinno trwać jak najkrócej. Technologia ADO początkowo nie pozwalała na tworzenie tzw. rozdzielonych zbiorów rekordów. W ADO 2.0 wprowadzono rozdzielone zbiory rekordów. Dzięki temu możliwe stało się utrzymanie na stosunkowo niskim poziomie liczby równoczesnych połączeń z bazą. Aplikacja łączyła się z bazą, odczytywała zbiór rekordów, a następnie zwalniała połączenie. Problem pojawiał się jednak w chwili, gdy taki zbiór danych miał być przeszukiwany czy aktualizowany. Microsoft wprowadził więc do ADO 2.1 możliwość definiowania indeksów (co przyspieszało wyszukiwanie), a także określił, w jaki sposób można ponownie wiązać rekordy z bazą danych. Niestety, niewiele dostawców OLE DB pozwalało realizować te funkcje.

Konieczność rozszerzenia ADO została wymuszona również rozwojem XML, który umożliwił zapis zarówno danych tablicowych, jak i informacji hierarchicznych. ADO może "wczytywać" odpowiednio sformatowany plik XML i tworzyć odpowiadający mu zbiór "rekordów" w pamięci. Przetwarzanie takich informacji jest jednak skomplikowane. Z jednej strony programista może wykorzystywać XML DOM (standard modelu obiektowego W3C dostosowany do obsługi XML), z drugiej, ma do dyspozycji ADO, w którym zupełnie inaczej niż w DOM wyszukuje się rekordy czy filtruje informacje. Integracja ADO i XML, jakkolwiek możliwa, nie jest łatwa.

Ostatni problem jest związany z czysto COM-owym "rodowodem" ADO. Recordset ADO jest strukturą COM, która może być przekazywana między poszczególnymi elementami tworzącymi warstwy aplikacji. DCOM pozwala przekazywać je między różnymi komputerami. Taki sposób przesyłania danych przez Internet nie jest jednak łatwy. Chcąc stworzyć usługę Web, która zwraca użytkownikowi określone informacje, ze względów bezpieczeństwa nie można przesyłać bezpośrednio ADODB.Recordset.

Nowy dostęp

ADO+ stanowi propozycję przebudowy ADO. Microsoft zamierza dostosować ten interfejs do architektury zgodnej z .NET przy zachowaniu istniejącego modelu obiektowego.

W ADO+ duży nacisk położono na ułatwienie obsługi rozdzielonych zestawów danych. Programista może definiować tzw. DataSet, będącą specjalną bazą danych (w pewnym sensie odpowiadającą IMDB z COM+). Zapewnia ona wykonywanie podstawowych operacji na danych. W DataSet może być wykorzystanych wiele różnych źródeł informacji, które ponadto mogą być połączone relacjami lub mogą określać hierarchię danych.

DataSet nie jest ściśle połączony z bazą. ADO+ samodzielnie określa, jak zbiór danych będzie wypełniany, które z operacji będą przesyłane do serwera itp. Programista nie musi troszczyć się o ponowne "połączenie" z bazą danych i przesłanie uaktualnionych czy nowych rekordów. Obsługę sytuacji szczególnych zapewnia ADO. Programista musi jedynie zapewnić obsługę błędów. ADO+ informuje, że niektóre z wierszy zostały zmienione, gdy Data-Set był odłączony.

DataSet przechowuje wszystkie informacje w formacie XML. Nawet jeżeli dany zbiór DataSet musi być przesłany między komputerami przez Internet, to nie sprawia problemów napotkany po drodze firewall czy inne zabezpieczenie. Cała komunikacja odbywa się przy użyciu protokołu HTTP lub HTTPS.

W ADO otwierany plik XML musiał mieć ściśle zdefiniowaną strukturę, z dużą liczbą metadanych określających typy pól. W ADO+ otwarcie dowolnego XML powoduje, że powstaje odpowiadający mu DataSet.

Z poziomu pakietu narzędziowego Visual Studio .NET ADO+ pozwala na graficzne definiowanie DataSet. Programista posługuje się interfejsem zbliżonym do tego, który pozwala określać relacje pomiędzy tabelami w bazie danych, z tym, że w tym przypadku powstaje ciąg instrukcji, który konstruuje relacje w DataSet. Elementy "tablicowe" mogą pochodzić z dowolnej bazy.

W ADO+ Microsoft pozwolił na tzw. mocne definiowanie typów. Poprzednio, jeśli programista chciał odwołać się do konkretnego pola w zbiorze rekordów, musiał posługiwać się tzw. kolekcją. Odwołanie do konkretnego pola następuje albo za pośrednictwem nazwy, albo przy użyciu indeksu. Powodowało to, że w czasie działania aplikacji kolekcja była wielokrotnie przeszukiwana. Ponadto wartość pola była określona jako Variant (uniwersalny typ pozwalający przechować niemal dowolną wartość). Było to bardzo wygodne w przypadku skryptów ASP, gdzie programista nie musiał dbać o poprawną konwersję danych itp. Jednak brak tej kontroli powodował trudne do wykrycia błędy w programie (niepoprawne nazwy pól czy obsługa wartości Null). ADO+ pozwala (dzięki wykorzystaniu specjalnych modułów do projektowania DataSet), by odwołanie do pola tabeli było kontrolowane w czasie kompilowania aplikacji. Zamiast posługiwać się kolekcjami, można odwołać się bezpośrednio do pola "struktury" odpowiadającej danemu wycinkowi DataSet. Jest to znacznie szybszy sposób odwoływania się do pól, a przy tym zabezpiecza przed powstawaniem prostych błędów.

Ewolucja

ADO+ nie jest zmianą rewolucyjną, jaką było przejście z interfejsu DAO do ADO. Dzięki obsłudze XML została ułatwiona komunikacja pomiędzy poszczególnymi elementami rozproszonej aplikacji. Można bez trudu przyjmować dane z dowolnego systemu, byle tylko baza mogła zapisać je w formacie XML.