明輝手游網(wǎng)中心：是一個免費提供流行視頻軟件教程、在線學習分享的學習平臺！

ADO.NET：通向未來之橋

發(fā)表時間：2024-06-13 來源：明輝站整理相關軟件相關文章人氣：

[摘要]在Web跨入編程時代之前，對于大多數(shù)IT管理者和顧問來說，數(shù)據(jù)訪問只是一個相對而言的問題；所有要用到的數(shù)據(jù)都必須自己準備好。人們主要關心的問題是選擇性能/價格比最好的數(shù)據(jù)庫服務器，系統(tǒng)涉及的所有模塊必須和服務器兼容�？蛻魴C/服務器應用是這種兩層模型最典型的范例。 隨著Web交互性的日益提高...
    在Web跨入編程時代之前，對于大多數(shù)IT管理者和顧問來說，數(shù)據(jù)訪問只是一個相對而言的問題；所有要用到的數(shù)據(jù)都必須自己準備好。人們主要關心的問題是選擇性能/價格比最好的數(shù)據(jù)庫服務器，系統(tǒng)涉及的所有模塊必須和服務器兼容。客戶機/服務器應用是這種兩層模型最典型的范例。

    隨著Web交互性的日益提高和應用的日益廣泛，對于第三層——中間層的需求也越來越突出。中間層是一個邏輯層，數(shù)據(jù)訪問組件通常就在這一層上。數(shù)據(jù)訪問組件是唯一有必要了解數(shù)據(jù)庫細節(jié)的代碼，同時，準備更換或者升級數(shù)據(jù)庫服務器時，數(shù)據(jù)訪問組件也是第一個需要修改的地方。

    接下來，三層系統(tǒng)模型發(fā)展成了Windows DNA——現(xiàn)在稱為Microsoft .NET服務器系統(tǒng)。Microsoft利用一個統(tǒng)一的模型進行數(shù)據(jù)訪問。這個模型注重的是內(nèi)容，而不是數(shù)據(jù)格式和存儲媒介。它的具體表達方式建立在UDA（Universal Data Access，通用數(shù)據(jù)訪問）的基礎之上，而UDA正是激勵OLE DB體系發(fā)展的深層理念。為了提供一種通過VB和ASP COM組件方便地、無縫地訪問OLE DB功能的途徑，Microsoft設計了ADO。ADO 2.0是用來支持OLE DB的第一個版本。在幾年之內(nèi)，ADO發(fā)展到了2.6版本，增加和擴展了XML支持，使得經(jīng)過擴展的ADO對象模型能夠匹配所有OLE DB改進功能（例如，對于OLE DB新增的Row和Stream對象，ADO 2.5提供了類似的ADO配套功能）。

    ADO 2.0的核心功能超越了OLE DB。在多層系統(tǒng)中，隨著中間層組件的出現(xiàn)，如何為表現(xiàn)層提供最新數(shù)據(jù)這一問題也隨之出現(xiàn)。表現(xiàn)層怎樣訪問數(shù)據(jù)？連接怎樣打開？或者，我們是否應該維護一份脫機記錄（即，一些斷開連接之后仍舊能夠在表現(xiàn)層使用的數(shù)據(jù)庫記錄）？ADO 2.0以及它的更高版本同時提供了對服務器端游標和脫機記錄集的支持（脫機記錄集是一種COM對象，它可以跨越網(wǎng)絡串行化，客戶可以下載它然后脫機使用）。 

    服務器端游標代表著一個緊密結合的、保持連接的環(huán)境，在這個環(huán)境中我們總是維持著各個層之間的有效通道，只有結束時才拆除連接。與此相反，脫機記錄集是一個有狀態(tài)的對象，我們可以把它作為一個整體處理，且不必維持連接。脫機記錄集使用客戶端的靜態(tài)游標，能夠提供一個數(shù)據(jù)源的快照。對于那些只有讀取要求、且需要在各個系統(tǒng)層之間移動數(shù)據(jù)的應用程序來說，脫機記錄集是很理想的。今天，大多數(shù)Web應用程序要求在各個層之間傳輸數(shù)據(jù)。為了獲取這些數(shù)據(jù)，我們經(jīng)常使用快速的“只能向前”游標，用XML編碼數(shù)據(jù)，然后通過網(wǎng)絡發(fā)送數(shù)據(jù)，避免了在Web服務器上維持會話狀態(tài)信息。在分布式環(huán)境中，數(shù)據(jù)庫連接是一種關鍵性的資源，以脫機方式工作保證了高可伸縮性。

    然而，Web是一把雙刃劍。Web讓我們連接到任何類型的聯(lián)機服務，而且能夠與它們進行交互。但是，Web也要求一定程度的互操作性，因為操作所涉及的各個服務可能運行在不同的軟件和硬件平臺上。我們可以通過利用開放的標準，以及那些不注重私有權的技術——甚至是象COM+這類廣泛應用的私有技術，跨越不同的平臺。

    今天，基于Windows的Web數(shù)據(jù)訪問應用程序利用了ADO豐富的、方便的編程接口。然而，ADO對象天生地定位在Windows平臺上。ADO基于COM的本性使得記錄集很難在一個分布式、異種平臺構成的環(huán)境中使用。另外，即使目標平臺可能允許我們使用ADO記錄集，它也不具備最有效的機制。ADO.NET的DataSet和DataReader更有效；而且，如果沒有ADO.NET，有些時候我們還可以借助XML或純文本獲得高效率。

    為了在Web環(huán)境下傳輸數(shù)據(jù)，Microsoft對ADO記錄集進行了優(yōu)化。但COM類型轉(zhuǎn)換仍舊是一個必不可少的步驟，因為COM的數(shù)據(jù)類型不可能總是匹配ADO記錄集的數(shù)據(jù)類型（例如，String類型必須轉(zhuǎn)換成BSTR類型）。由此，許多人把XML當成了粘合各個層的“萬能膠水”——不管涉及到了哪些平臺。通常的做法是：先提取一個記錄集，把它保存為XML格式，然后傳輸結果數(shù)據(jù)流，讓接收者從這個XML數(shù)據(jù)流重新構造出記錄集供以后使用。隨著對協(xié)同工作能力和可伸縮性要求的提高，ADO不再是最理想的答案，因為它不是建立在XML的基礎上——但ADO.NET是。

二、ADO在Web環(huán)境中的不足

    .NET框架創(chuàng)立了一種取代COM和COM+的新組件模型。.NET的提出是Microsoft成熟的組件技術的新戰(zhàn)略。雖然幾個關鍵性的COM特色不再在.NET中出現(xiàn)，但在某些方面，.NET與COM編程仍舊很相似。因此，COM程序員將能夠方便地轉(zhuǎn)向.NET開發(fā)。ADO.NET是Microsoft特別為.NET框架設計的數(shù)據(jù)訪問層，它在很大程度上利用了.NET的優(yōu)勢。

    為什么.NET必須用一個新的數(shù)據(jù)訪問層來替代現(xiàn)有的、廣泛應用的數(shù)據(jù)訪問接口，比如ADO？現(xiàn)代Web應用系統(tǒng)必須具備客戶機/服務器應用和桌面應用的交互能力，Microsoft設計.NET的目標正是為了迎接設計現(xiàn)代Web應用系統(tǒng)的挑戰(zhàn)。同時，.NET也利用了各種Web協(xié)議廣泛的、強大的連接能力和協(xié)同操作能力。

    在非Windows平臺上，ADO記錄集不能直接使用，從而使得協(xié)同操作能力受到了限制。為了突破這個限制，我們要把記錄集轉(zhuǎn)換成XML格式，然后傳輸轉(zhuǎn)換得到的XML記錄集。在ADO.NET中，把數(shù)據(jù)轉(zhuǎn)換成XML以及通過網(wǎng)絡傳輸?shù)牟僮鞯玫搅撕喕蛢?yōu)化。另外，ADO對象模型中的每一個地方都體現(xiàn)了以數(shù)據(jù)庫為中心的思想。ADO把數(shù)據(jù)看成是一組來自數(shù)據(jù)源的記錄，而不是把數(shù)據(jù)看成一些獨立的信息。在ADO中，如果脫離了數(shù)據(jù)提供者用來保存和描述數(shù)據(jù)的結構，數(shù)據(jù)將不能獨立存在。

三、ADO.NET數(shù)據(jù)集和ADO記錄集

    ADO.NET是從Web的角度對ADO進行檢討和改進。Microsoft對ADO.NET的設計嚴格地體現(xiàn)了其名字的含義：ADO，再加上.NET。ADO.NET自動連接網(wǎng)絡，致力于讓Web數(shù)據(jù)訪問變得更加簡單和高效。兩個功能使得這方面的增強成為可能：脫機記錄集，以及與生俱來的對XML的支持。由于采用了脫機記錄集方案，ADO.NET自然也就不再支持服務器端游標。ADO.NET天生就把記錄數(shù)據(jù)保存為XML文檔，把模式（Schema）和數(shù)據(jù)視為分離的、可替換的元素。

    如果你認為ADO早就提供了這些功能，它們并沒有什么創(chuàng)新意義，那么，ADO.NET還提供了其他許多新的功能。ADO.NET能夠使用連接的或者非連接的（脫機的）記錄集，具體由用戶選擇的游標類型和游標位置決定。ADO記錄集的本地存儲格式是ADTG文件格式（Advanced Data TableGram，高級數(shù)據(jù)表圖）。ADTG是一種Microsoft私有的二進制存儲模式，代表著記錄集在內(nèi)存中的映像。XML是可替換使用的、確定的、詳細輸出格式。在ADO.NET中，我們可以斷開一個記錄集集合的連接，通過一個默認（但允許更改）的XML模式再現(xiàn)記錄集集合。

    在ADO.NET對象模型中，DataSet（數(shù)據(jù)集）是最重要的對象。一般地，一個DataSet對象就是一個記錄集的集合。ADO.NET框架提供了記錄集的所有數(shù)據(jù)庫功能：排序，分頁，過濾視圖，關系，索引，和主鍵。

    DataSet對象代表了一個在內(nèi)存中的、有著豐富功能的數(shù)據(jù)緩沖區(qū)。DataSet對象也通過表組織數(shù)據(jù)，這些表與原始的數(shù)據(jù)源之間不存在連接。我們可以添加表，表可以通過讀取本地或遠程XML文件獲得，或者也可以從任何可訪問的系統(tǒng)資源（包括內(nèi)存和其他附屬設備在內(nèi)）讀取。我們可以排序、索引、過濾數(shù)據(jù)表，象處理ADO的Recordset一樣導航數(shù)據(jù)表。

    我們可以通過命令用數(shù)據(jù)集合填充DataSet對象。如果用.NET集合的形式為DataSet對象提供數(shù)據(jù)表（具有集合功能的.NET數(shù)據(jù)類型是ICollection），同一個DataSet對象能夠服務來自多個連接的多個請求。ADO.NET的DataSet對象比ADO的Recordset更一般化；與ADO的Recordset不同，它是對數(shù)據(jù)源的一種抽象。然而，DataSet對象保留了一個在內(nèi)存中工作的數(shù)據(jù)存儲器；它沒有完全淘汰記錄集功能。如果我們只需要一次性地滾動記錄集，然后生成某種輸出，那么，我們應該使用DataReader對象。.NET的DataReader對象類似于“只能向前、只讀”的記錄集，但它是一個高度專用化的對象，所以無論在體積和開銷上它都要比記錄集小。事實上，記錄集能夠執(zhí)行許多不同的任務，是一個相當臃腫的對象。與ADO的Recordset相比，DataReader不包含進行“家務管理”的代碼，除了實現(xiàn)功能所必需的代碼之外，它不包含任何其他代碼。

    把多個表作為一個整體管理以及允許建立這些表之間的關系，這是ADO.NET的新功能。我們可以用XML形式持久化或傳輸任何DataSet對象，而且無需付出任何額外的代價，因為DataSet對象本身就是按照XML格式構造。因此，除非要修改底層模式，否則，我們無需為了獲得一個XML流而去轉(zhuǎn)換DataSet對象的任意一個部分。

[1] [2] [3]  下一頁