關于 OLE DB 和 .NET 的思考
2024-07-21 02:08:57
供稿：網友
關于 ole db 和 .net 的思考
你我并不相識。不過，面對一個實實在在的問題“軟件到底是什么？”，我卻沒有合適的答案。
設想一下這樣一個場景：在一個旅游紀念品商店，你正專注于購買一些沒用的東西（主要是紀念品），以便讓到機場接你的朋友和親戚感到開心。這時，往往會有人問你：“第一次來嗎？出差還是度假？”
所以，如果你是在做和軟件有關的事，而不是在度假，那你就不得不面對這個現實的問題。
那么，軟件到底是什么？
回答這種關于存在的問題是很困難的，尤其是如果此時你正在閑逛，背著一背包明信片、考拉圖片和袋鼠玩具，包上還印著防鱷魚的黃色警告標志。
我努力使自己的思維自由而又盡量簡單。首先，軟件是跟計算機相關的。軟件也和演變有關。當然，軟件還與數據（特別是數據存儲和操作）有關。
回到旅館后，我仍在思考下面的問題——關于數據的存儲和使用，我近年來觀察到了怎樣的演變？于是，我開始思考 ole db 及其在 .net 方面的演變。
軟件進化論
從歷史角度來說，odbc 進行了第一次嚴肅嘗試：它試圖創建一種統一的應用程序訪問數據庫的途徑。像軟件中的其他東西一樣，odbc 的設計目的是滿足某種特定的需要。在信息技術永無止境的進化進程中，它開創了一個新階段。
odbc 必須提供一個公用的（最好是抽象的）api，用來訪問數據庫，而不用考慮數據庫的內部細節、語言和表的組織。但是，隨著時間的推移，人們發現，面對新的數據驅動應用程序的設計與構造方法，odbc 越來越無法成功地滿足需要。
軟件也有自己的進化論。odbc 以不同的名稱、不同的編程模型和新的功能適應了變化，生存了下來，同時又保持了它的真正使命。odbc 繼續以 ole db 的名稱和功能提供（或多或少地）開放式數據庫連接的功能。
ole db 作為一種編程接口，將 microsoft 通用數據訪問 (uda) 策略的理論概念應用于實踐。uda 能夠通過基于 com 的單一編程接口來訪問各種類型的數據，包括關系型、非關系型和層次結構型數據。
ole db 是作為一種組件技術而設計的，其特點是采用了多層模型。在 com 橋的一側是用于保留數據的服務器組件，另一側則是了解如何連接和請求數據的客戶端組件。前者稱作 ole db 數據提供者；而后者則稱作 ole db 使用者。
使用者和提供者都是 com 對象，并能夠通過一套 com 接口互相通信。這種基于 com 的通信可被概括為在抽象對象（如 datasource、session、command 和 rowset）上執行的操作。因此，當使用者連接到 datasource，打開 session，發出 command，并返回數據 rowset 時，便會出現這種情況。
odbc 的這一進化使 uda 和 ole db 添加了一種功能，這種功能就像一個簡單的關系表一樣，將所有的企業數據粘合在一起，不論它們是關系型、非關系型還是層次結構型。
ole db 模型
說到數據訪問，我們有兩種基本選擇。一種是像 uda 允許的那樣，采用通用數據訪問策略。另一種則傾向于使用通用數據結構。它強行將現有的所有信息從當前的數據存儲區移動到一個能包容所有數據類型的數據庫服務器。
使用 ole db，需要將客戶所有的信息粘合在一起。另一種方式是，強行將客戶端升級至新的、更強大的、唯一的 dbms，而這個 dbms 能夠處理任何格式的信息。
與 odbc 相比，ole db 對數據物理結構的依賴更少。此外，它不必嚴格基于 sql。ole db 命令可以是 sql 語句，也可以是其他的一些東西。總的說來，可以將它們看作以任何能夠為目標提供者理解的語法寫成的文本字符串。
像 odbc 一樣, ole db 采用 c++ 的概念進行設計，以盡可能提高中間層模塊數據訪問的性能。基于同樣的原因，ole db 不能直接在 visual basic® 或 asp 中使用。
而不計其數的分布式系統卻是使用 visual basic 來生成組件的。這就是 microsoft 引入 activex® 數據對象 (ado) 庫的主要原因。
ado 的編程接口比原始的 ole db sdk 更加豐富。雖然在 c++ 應用程序中使用 ado 是完全可行的，但是 ole db 調用經過的代碼層次較少，與相應的 ado 代碼相比，能更直接地到達數據。
雖然 ado 很明顯是在 ole db 上生成的，但是調用原始 ole db 接口和通過 ado 運行時發出的調用具有不同的相對速度。這一事實導致了語言之間的差異。哪一種更好、更值得推薦呢？是 ole db 的 c++ 高性能層次還是 visual basic 組件中更簡單、更友好的 ado 模型？
除了提供者和使用者，ole db 模型還包括第三個元素——ole db 服務。服務是一種 com 組件，用于處理返回給使用者的“行集”。它就像掛鉤一樣工作，監督使用者和提供者之間的所有通信。ado 在很大程度上依賴 ole db 服務來添加其擴展功能，如數據塑型、持久性和斷開的記錄集。
因此，自從人們開始重視構建基于 com 的分布式應用程序以來，就開發了各種針對某些特定領域的最佳實例。為改進 web 應用程序的可伸縮性，人們轉而使用數據訪問斷開模型。
簡單說來，數據使用者和數據提供者并不總是連接的。一旦建立了連接，便可以發出指定的查詢，獲取記錄并將其放至內存中的存儲庫，然后從數據源斷開連接。然后您再在脫機狀態下處理這些記錄，并在需要時重新連接或提交更改。這一模型不是在所有情況下都可以使用，不過，一旦它發生作用，您就會發現它在可伸縮性和總體性能方面非常有價值。
許多系統已經進行了轉換（或再轉換），通過客戶端游標服務來部署 ado 記錄集，從而啟用數據斷開。ole db 還不是專用于此類交互的模型，所以 ado 是通過中間 ole db 服務進行擴展的。
由于其結構所固有的靈活性，ole db 可以成功地應用于斷開連接方案，但是，這當然不代表最佳的工作方式。這一實現方案的另一小小的限制是：方案較多地依賴 ado 記錄集進行工作，以至于人們懷疑它不可能總是把每件事都做好。這樣的對象如何才能在各種情況下成為最快的工作工具，不論是連接還是斷開，有沒有 xml，是創建的還是從磁盤加載的？
此外，考慮到 ado 的功能包與原始 ole db sdk 顯著不同，使用 ole db 將導致明顯的不一致現象。
因此，ado.net 成為數據訪問技術進化中的下一步驟。不過，從名稱上看來，ado.net 似乎只是 ado 的繼承者。.net 中的 ole db 又是怎樣的？
.net 托管提供者
永恒的進化論規律現在將 ole db 技術向前推進了一步，以滿足新用戶的要求。在 .net 中，web 應用程序首先是一個斷開的應用程序，它利用新設計的特殊工具來管理數據。
.net 框架使得類能夠處理數據。這些類——特別是 ado.net 和 xml 名稱空間——可供收集、讀取和寫入。ado.net 和 xml 子系統最終取代了 ado 和 ole db sdk。現在，您擁有了一個唯一的、以語言為中心的方法來獲取和設置數據。
ado.net 類對數據源的抽象能力甚至比 ado 還要好，因為它明確設計為以數據為中心，而 ado 中仍然使用以數據庫為中心的設計。
.net 中對應于 ole db 數據提供者的部分稱為“托管提供者”。它們的作用如下圖所示。
圖 1：托管提供者層次結構圖
在 ole db 中可以按照相似性來識別兩個交互的層，即我上面提到的托管使用者層和托管提供者層。在處理數據時，.net 應用程序不必將特殊的類或組件作為使用者模塊使用。
如果 .net 應用程序只使用本機框架中的 dataset 或 datareader 對象，則其將立即成為“托管”數據使用者。要真正地獲取數據，應使用從 datasetcommand 和 dbcommand 中繼承的特殊類的實例。這些類代表了到數據源的鏈接。
你只需使用了解如何處理給定提供者的導出類，而不用指導通用對象來處理給定的提供者。所以出現的情況是，sqldatasetcommand 將處理 sql server 數據庫，而 adodatasetcommand 將包裝所有現有 ole db 提供者。
托管提供者將隱藏在這樣的 datasetcommand 類中。你永遠不會意識到它們的存在，也無需特意了解它們。只要使用類和設置屬性就可以了，這讓人感到愉快。
在這種情況下，上圖中的托管提供者層使用的交互模塊與 ole db 甚至更早的 odbc 中使用的模塊沒有太大不同。使用者命令類針對的是包裝數據源的特定組件。它了解用于在源中讀寫數據行的協議。它還以一種 .net 類能夠很好處理的格式返回結果。
為便于理解，讓我們回顧一下 ole db 和 .net 數據檢索的共性。
ole db 提供者.net 托管提供者標識com progid包裝在命令類中返回結果rowset 或 ado recordsetdataset 或 datareader 類更新方式提供者的特殊命令提供者的特殊命令傳送格式二進制xml
表 1：比較 ole db 和 .net 數據提供者
目標提供者是通過其位于 ole db 中的 com progid 來識別的，而在 .net 中，這些細節隱藏在訪問器類中。
ole db 提供者總是返回行集——com 對象主要提供 irowset 接口。如果通過 ado 訪問數據，行集會轉換為更豐富和更腳本化的對象，稱作記錄集。
.net 應用程序只使用具有不同功能的各種類。datareader 類是一個簡單、快捷、只能前進的游標，在連接狀態下工作并按記錄來提供訪問。結束后必須顯式斷開連接。相反，dataset 對象是內存中的斷開連接集合表。它是 datasetcommand 類的填充的實例。dataset 對象的內容建立在 datasetcommand 從數據源取回的 xml 流的基礎上。
我將在以后的專欄中講述有關 datareader 和 dataset 的內容。
數據以二進制格式從提供者到達使用者，如果部署了 ole db，則還會經過 com 配置。而在 .net 中，托管提供者將返回一個 xml 流。
兩種提供者都支持查詢語言（通常是 sql 和各個供應商特有的擴展）。通過該語言可以執行更新和詢問數據源。
那么，ole db 數據提供者和 .net 數據提供者之間的區別是什么呢？抽象地說，它們使用相同的數據訪問策略。但是托管提供者更加簡單和專業。兩個主要的原因導致了其性能的優越性。首先，托管提供者不使用 com 互操作橋來獲取和設置數據。作為 com 組件，ole db 提供者在這一點上別無選擇。其次，托管提供者通常利用來自供應商的內部數據源知識來更快地獲取和設置行。ole db 提供者也是這樣做的，但是當在 .net 內部使用時，ole db 提供者必須為其基于 com 的特性付出代價，并且需要額外的代碼將數據轉換為 .net 特有的類。
現有的托管提供者
像在 beta 1 中一樣，net 框架的特色是具有兩個托管提供者：一個用于 sql server（7.0 版本或更高），一個用于所有能夠通過 ole db 提供者獲得的數據源。
sql server 托管提供者隱藏在特定的類（如 sql datareader、sql datasetcommand 和 sqlcommand）后。這些類直接訪問低層的 sql server 文件系統。下圖是提供者的類圖。該圖將以前的通用架構映射至 sql server 托管提供者。
圖 2：sql server 托管提供者的類圖
ole db 托管提供者在 .net 中的作用與 odbc ole db 提供者在 windows dna 系統中的作用是相同的。簡單說，它體現了后向兼容性，也反映了這樣一個事實，即所有 .net 應用程序均可以面向任何以 ole db 為基礎的現有數據源。ole db 托管提供者的類圖如下所示。
圖 3：ole db 托管提供者的類圖
請注意在 beta 2 中，adoxxx 類需要重命名為 oledbxxx。
ole db 托管提供者將 .net 類提供給調用方，但利用指定的 ole db 提供者來獲取行。.net 應用程序與底層 ole db 提供者（com 對象）之間的通信通過 com 互操作橋發生。
總的來說，在 .net 中通過上述兩個提供者均可以訪問 sql server 7.0（及更高版本）的表。sql server 的托管提供者直接從 dbms 文件系統請求數據，而 ole db 托管提供者依賴 sqloledb ole db 提供者的服務，從而導致需要經過額外層次的代碼。
現在，如果你面對的是 sql server 以外的任何數據源，那么 ole db 托管提供者是唯一的通道。通過同一通道，你還可以到達任何 odbc 數據源。
ole db 托管提供者是在 com 互操作橋上生成的瘦包裝，可以調入本地 ole db 提供者。除了設置和終止調用，這一模塊還負責將返回的行集包裝至 dataset 或 ado datareader 對象，以便進行后續 .net 處理。
在 .net 代碼層，通過本地托管提供者或 ole db 提供者訪問 sql server 表實際是對涉及到的類的前綴進行更改。以下是用于 sql server 的代碼：
dim strconn, strcmd as stringstrconn = "database=northwind;server=localhost;uid=sa;pwd=;"strcmd = "select * from employees"dim ocmd as new sqldatasetcommand(strcmd, strconn)dim ods as new datasetocmd.filldataset(ods, "employeeslist")
以下是用于 ole db 提供者的代碼（不同之處以粗體表示）：
dim strconn, strcmd as stringstrconn = "provider=sqloledb;" strconn += "database=northwind;server=localhost;uid=sa;pwd=;"strcmd = "select * from employees"dim ocmd as new adodatasetcommand(strcmd, strconn)dim ods as new datasetocmd.filldataset(ods, "employeeslist")
由此可見，表面上的不同是非常小的；只有連接字符串和命令類不同。而使用一種類還是另一種類，差別卻是非常大的。
ole db 的存在性問題
.net 托管提供者代表了數據訪問技術演化的下一步發展方向，但是，在 beta 1 中還沒有文檔化的 sdk 涉及數據源特定的托管提供者。幾個關于 ole db 和 .net 的基本問題是無法忽略的。它們正在等待著 beta 2。
難道為 ole db 開發的所有代碼只是過時的代碼嗎？公司已經投入（而且經常是仍然在投入）的為自己的數據編寫提供者的一切努力將會如何？
堅守你的信念——ole db 不是一項消亡的技術。尤其是對于功能豐富、通用并且獨立于 .net 的編程接口，它仍然是基本的規范。它不專門針對 .net，但它獲得了很好的支持。
這就是說，如果要公開自定義數據，就不能忽略 .net 和托管提供者的出現。那么，什么是包裝數據提供者的最佳接口呢？你應該怎樣計劃盡快公開你的數據呢？例如，從下個星期一上午 8 點開始？
.net 使用開放的標準并廣泛地基于 xml。在這種情況下，如果你需要公開擁有所有權而又基于文本的數據，則只需要考慮使用 xml（可能是自定義方案）來發布。在 .net 中有這么多的工具可與 xml 數據配合工作，包裝類的生成應該完全沒有問題。
對于更復雜的數據存儲，ole db 提供者仍是有意義的，因為你的用戶群更大，而且可能不僅僅局限于 .net。對于 .net 專有的應用程序，托管提供者當然可以提供巨大的性能優勢，但我對此持非常謹慎的態度——尤其是要在這樣短的時間內做出決定！不要忘記，目前為止還沒有發布有關托管提供者的任何 sdk，盡管 microsoft 已經做出了這樣的承諾。
總之，這個星期一早晨我將要開始編寫的下一個數據提供者將會包括一對 ole db 數據提供者和一個使用 xml 的 .net 包裝類。我的首要選擇不會是用 .net 類通過 com interop 來包裝 ole db 提供者。我寧可使用同樣的、經過一定調整的源代碼。在這種情況下，托管 c++ 很可能是便于重用“物理”代碼的最佳語言。
ole db 的結局
讓我們將此作為一種預言，留待從現在開始的未來幾年驗證。我要冒昧地說，ole db 將與 sgml（標準通用標記語言，xml 的前身）一樣，其最終結局不會很理想。
作為數據交換世界的救世主而引進的 sgml 從來沒有成為事實上的標準，也許是因為對于日常使用來說它太過強大和復雜了。事實是，它令人激動的原理經過了適當的縮減和特殊化，并生成 xml，然后才被廣泛地接受。
我的預言是，一旦 .net 穩固了其基礎，ole db 將逐漸喪失其重要性，直至最終消失。我不能確定這一過程將會持續多長時間，但我確信這一點。
論據就在后面 <g>。不要走開。
對話：是的，現在我覺得過時了
你很可能生活在另一個時空！你該如何將現有的 ado 代碼定義為陳舊代碼（在大多數情況下，這些代碼是在六個月內寫成的。）？以 .net 技術/平臺的名義？它甚至還沒有進入 beta 程序的第二階段。
沒有任何重點的生活是什么樣子的？無論如何，這個問題問得好。
面對近來許多 dna 系統中的 ado 代碼，我們能夠將它們定義為陳舊的代碼嗎？我的答案仍是：“是的，我們會。”但是我確實理解，這聽起來實在令人迷惑。
我認為，“陳舊代碼”就是不再適合宿主平臺核心的代碼。相信我，這的確是 .net“即將”面對的狀況。當然，還是有方法在 .net 中將現有代碼、組件和應用程序結合起來的。
.net 是一場非暴力革命，在未來的幾年中，它將吸取 windows 軟件中的任何有生命力的實例。反抗是徒勞的——你注定會被同化。無論代碼的年齡如何，在我對“陳舊”的定義中，真正重要的是源代碼與運行時的一致性。
.net 改變了 windows 運行時，使其被托管。雖然 com 和 windows sdk 還沒有完全喪失生命力，但你必須根據另一個模型來編寫代碼。不管這一新的運行時的基礎是什么，一種嶄新的模型將會與舊模型展開競爭。這一新模型將是未來 windows 的模型。
windows 不會滅亡，但是它將改變。com 不會滅亡，但它將不得不面對 .net 類。ado 不會滅亡并將繼續發揮作用，但是以 ado.net 為特點的 .net 才是 ado 的未來。
.net 并不簡單的就是 windows 6.0，ado.net 也不是以前稱作 ado 3.0 的奇妙新名字。它是不同的，又是普遍適用的。它是新的平臺。其他的內容或者是另一個平臺，或者是陳舊的代碼（當集成在一起時）。
陳舊代碼是不論存在時間的。我知道人們還是會編寫 dna 系統，在這一周，在六個月內，甚至在 .net 發布后。我并不是說這是完全錯誤或是應該絕對避免的。只是要提醒你，你正在逆潮流而動。
