ADO+ 引導數據種類的演變
Dino Esposito
2000年9月
摘要： 本文討論了 ADO 的最新版本 ADO+ 所提供的增強的互操作性和可伸縮性。
目錄
簡介
一種公用數據操縱語言
數據種類
ADO+ 增加了哪些內容
ADO+ 的構成要素
ADO+ 命令
強類型編程
摘要
--------------------------------------------------------------------------------
簡介
從一開始，開發軟件應用程序就是為了訪問某種數據庫。分布式應用程序和基于 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 記錄集 — 表或視圖的 ADO 表示 — 是一個相當不錯的解決方案，它有幾個優點，并且只有一個大的缺點。
ADO 記錄集的靈活性足以使您能夠毫不費力地定位記錄以及使用過濾器和書簽。它們還提供排序、自動分頁和持久性等功能，并能在與數據源斷開時工作�？梢栽诙鄬又g相當高效地匯集記錄集，這歸功于其固有的并且極為緊湊的二進制格式 — Advanced Data Table Gram (ADTG) 格式。
斷開的記錄集在組件之間的傳輸涉及到 COM 匯集，并強制接收組件配合這一匯集。換句話說，只有 COM 對象才能使用 ADO 記錄集。這在 COM/DCOM 在業務層中占主導地位的同構體系結構中不成問題。顯然，當有關的服務器端組件的映射涉及到諸如大型機或 Unix 平臺之類的異構節點時，就會帶來很大的不便。
所謂的 Internet 的第三個階段使這一方案離我們更近了。它預示了一個世界，在這個世界中，功能實現通過各種 Web 服務（即可以通過 HTTP 訪問的環繞著我們的衛星系統）成為可能。您將需要向這些服務中的某個傳遞一些記錄以進行進一步處理，這個方案并不是什么勉強的事情。沒有什么比 Web 服務更加容易的事了 — 不管它的內部體系結構或公共編程接口如何 — 它不接受 ADO 記錄集。
A目前現實中的 ADO，特別是記錄集，是在 Windows 和基于 COM 的方案中操縱數據的強有力的工具。不幸的是，隨著您的系統逐漸向完全的 Internet 互操作性方向演變，它們逐漸喪失了其吸引力。
--------------------------------------------------------------------------------
數據種類
在完美的情況下，應該能夠在任何平臺或設備上以相同的方式訪問數據，并具有相同的靈活性。這樣，每個平臺或設備都可以根據需要自由地操縱數據。如果您通過 ADO 記錄集展示數據，則您也使自己和您的應用程序陷于有限互操作性的實際風險之中。
目前，如果您通過 ADO 對數據進行訪問，并希望將其傳送到遠程組件，您要么使用從數據訪問模塊獲得的相同的 ADO 記錄集，要么將其轉換為能夠通過網絡傳送的另外的東西，更為重要的是，能夠在其最終目的地被理解。如前所述，記錄集需要 COM 匯集，舉例來說，COM 調用并不是總能穿過公司防火墻。此外，在對 ADO 記錄集進行匯集時，總處理時間的很大部分是用于完成必要的類型轉換。事實上，您必須確保記錄中的所有的值映射到 COM 能夠識別并知道如何進行處理的有效數據類型。
在有關的組件在物理上是分開的并在不同的機器上運行時，COM 匯集因素變得更為重要。因此，在向完全由 Internet 連接起來的世界前進的過程中，目前的 Windows 數據種類連同 ADO 記錄集必須有所發展才能繼續存在下去。
需要示例嗎？在 MIND 的 2000 年 1 月號（英文）以及 MSDN Magazine 的 2000 年 3 月號（英文）中的 Cutting Edge 專欄中，我對將遠程腳本 (RS) 用作一種從遠程 ASP 頁面獲取數據而不定位到該頁面的跨瀏覽器的技術進行了說明。當您以這種方式調用某一頁面上的遠程函數時，RS 基礎結構提供將函數返回的內容發送回客戶機。在大多數情況下，您需要返回一個記錄集。然而，由于安全性原因，RS 甚至不會嘗試連同任何其它 COM 對象對某一 ADO 記錄集進行處理。因而，如果使用 RS，您必須避免使用 ADO 記錄集，而應當使用數組或字符串傳遞所請求的信息。在 2000 年 3 月的專欄中，我通過從記錄集構建一個 JavaScript 對象對這一內在的限制進行了說明。ASP 頁面通過 ADO 獲取數據，并在返回調用程序前將其轉換為一個 JavaScript 對象：
rst = new ActiveXObject("ADODB.Recordset");
rst.open("select * from employees", "DSN=Northwind");
oRS = new Recordset(rst);
rst.close();
return oRS;
客戶機頁面通過 RS 運行時接收這一對象，并可以根據需要對其進行處理，這比通過字符串或數組要容易得多。詳細信息和源代碼，請參見我的 2000 年 3 月 Cutting Edge 專欄文章（英文）。
我們從這里可以學到些什么嗎？對于超出單一客戶機或服務器端平臺的數據互操作性，我們需要對 ADO 模型進行一個較小的改變。
我們需要改變是由于跨平臺模塊的交互作用需要一個通用數據模型。此外，我們不希望這個改變太大，原因是 ADO 內還存在若干很好的功能，放棄它們是一件可惜的事情。
JavaScript Recordset 對象，就其內在的簡單性而言，不過是一個次數的標志。我們需要提取 ADO 記錄集的本質，并將其重新構建成可以便利地在任意平臺上進行傳輸和處理的另外一種東西。HTTP 提供了得到廣泛接受的網絡渠道。XML 將廣泛接受的數據描述的基礎結構集合在一起。ADO+ 是對 ADO 的較小改進，它使之成為一個用于創建分布式和數據共享應用程序的基于各種標準的編程模型。
原作者：不詳
來 源：www.microsoft.com
文章來源于領測軟件測試網 http://www.kjueaiud.com/
