從一開始，開發軟件應用程序就是為了訪問某種數據庫。分布式應用程序和基于 Web 的應用程序也不例外。然而在分布式方案中，由于可能存在不同的硬件和軟件平臺或對象模型，事情變得稍微有點復雜。盡管如此，數據就是數據，在幾乎任何地方都需要得到交換和處理。
在我們進入可編程 Web 時代 — Internet 的第三個階段 — 之前，數據訪問曾是一個相對簡單的問題；主要關心的問題就是選擇效能成本最合算的數據庫服務器。任何系統的所有模塊都必須符合數據庫服務器 — 一種對整個系統進行完全控制的全能實體 — 的要求?？蛻魴C/服務器應用程序一直是這種模型的典型表現形式。
近來，n 層 Microsoft® Windows® DNA 系統致力于開發能夠對幾乎任何種類的數據進行迅捷可靠的訪問的技術，這些數據種類包括：關系型、非關系型、層次型、半結構化型、分散型、易失型等。這種數據訪問的統一方法成為“通用數據訪問”策略 — OLE DB 體系結構的鼓舞人心的原則。Microsoft ActiveX® Data Objects (ADO) 的出現完成了一項重大的任務：將成千上萬的 Windows 開發人員從過時的客戶機/服務器模型帶到數據訪問組件和 OLE DB 的奇妙世界。
在 Windows DNA 模型中，中間層組件通過 OLE DB 規范體貼地為我們定義的一種公用格式來獲取和交換數據。這種格式以行集格式為基礎，并且通常被轉換為諸如 ADO 記錄集之類的一種更高級的結構。
使用 ADO 記錄集有得有失。一方面，它們提供了一種豐富并具有吸引力的編程接口。另一方面，它們是嚴格基于 COM 的，在涉及許多平臺（尤其是非 Windows 平臺）的分布式異構環境中無法使用?；ゲ僮餍院涂缮炜s性是對現代 Web 系統的兩個很高的要求；互操作性和可伸縮性更好的數據訪問體系結構同樣是最新的 ADO 版本 ADO+ 中的主要變化。
一種公用數據操縱語言
通常情況下，目前的分布式系統符合圖 1 中所示的體系結構。
圖 1. 目前的分布式 Web 系統的典型體系結構
表示層通常基于 HTML 3.2 輸出，并能夠很好地與任何較新的瀏覽器一起工作。網頁是在 Web 服務器上使用 Active Server Pages (asp) 構建的，并且只有在一些相當特殊的情況下才試圖通過 COM、動態 HTML 和 xml 支持來提供瀏覽器的實際功能。
ADO 記錄集的靈活性足以使您能夠毫不費力地定位記錄以及使用過濾器和書簽。它們還提供排序、自動分頁和持久性等功能，并能在與數據源斷開時工作?？梢栽诙鄬又g相當高效地匯集記錄集，這歸功于其固有的并且極為緊湊的二進制格式 — Advanced Data Table Gram (ADTG) 格式。
斷開的記錄集在組件之間的傳輸涉及到 COM 匯集，并強制接收組件配合這一匯集。換句話說，只有 COM 對象才能使用 ADO 記錄集。這在 COM/DCOM 在業務層中占主導地位的同構體系結構中不成問題。顯然，當有關的服務器端組件的映射涉及到諸如大型機或 Unix 平臺之類的異構節點時，就會帶來很大的不便。
所謂的 Internet 的第三個階段使這一方案離我們更近了。它預示了一個世界，在這個世界中，功能實現通過各種 Web 服務（即可以通過 HTTP 訪問的環繞著我們的衛星系統）成為可能。您將需要向這些服務中的某個傳遞一些記錄以進行進一步處理，這個方案并不是什么勉強的事情。沒有什么比 Web 服務更加容易的事了 — 不管它的內部體系結構或公共編程接口如何 — 它不接受 ADO 記錄集。
A目前現實中的 ADO，特別是記錄集，是在 Windows 和基于 COM 的方案中操縱數據的強有力的工具。不幸的是，隨著您的系統逐漸向完全的 Internet 互操作性方向演變，它們逐漸喪失了其吸引力。
