你我并不相識(shí)。不過，面對(duì)一個(gè)實(shí)實(shí)在在的問題“軟件到底是什么？”，我卻沒有合適的答案。

設(shè)想一下這樣一個(gè)場(chǎng)景：在一個(gè)旅游紀(jì)念品商店，你正專注于購買一些沒用的東西（主要是紀(jì)念品），以便讓到機(jī)場(chǎng)接你的朋友和親戚感到開心。這時(shí)，往往會(huì)有人問你：“第一次來嗎？出差還是度假？”

所以，如果你是在做和軟件有關(guān)的事，而不是在度假，那你就不得不面對(duì)這個(gè)現(xiàn)實(shí)的問題。

那么，軟件到底是什么？

回答這種關(guān)于存在的問題是很困難的，尤其是如果此時(shí)你正在閑逛，背著一背包明信片、考拉圖片和袋鼠玩具，包上還印著防鱷魚的黃色警告標(biāo)志。

我努力使自己的思維自由而又盡量簡(jiǎn)單。首先，軟件是跟計(jì)算機(jī)相關(guān)的。軟件也和演變有關(guān)。當(dāng)然，軟件還與數(shù)據(jù)（特別是數(shù)據(jù)存儲(chǔ)和操作）有關(guān)。

回到旅館后，我仍在思考下面的問題——關(guān)于數(shù)據(jù)的存儲(chǔ)和使用，我近年來觀察到了怎樣的演變？于是，我開始思考 OLE DB 及其在 .NET 方面的演變。

軟件進(jìn)化論

從歷史角度來說，ODBC 進(jìn)行了第一次嚴(yán)肅嘗試：它試圖創(chuàng)建一種統(tǒng)一的應(yīng)用程序訪問數(shù)據(jù)庫的途徑。像軟件中的其他東西一樣，ODBC 的設(shè)計(jì)目的是滿足某種特定的需要。在信息技術(shù)永無止境的進(jìn)化進(jìn)程中，它開創(chuàng)了一個(gè)新階段。

ODBC 必須提供一個(gè)公用的（最好是抽象的）API，用來訪問數(shù)據(jù)庫，而不用考慮數(shù)據(jù)庫的內(nèi)部細(xì)節(jié)、語言和表的組織。但是，隨著時(shí)間的推移，人們發(fā)現(xiàn)，面對(duì)新的數(shù)據(jù)驅(qū)動(dòng)應(yīng)用程序的設(shè)計(jì)與構(gòu)造方法，ODBC 越來越無法成功地滿足需要。

軟件也有自己的進(jìn)化論。ODBC 以不同的名稱、不同的編程模型和新的功能適應(yīng)了變化，生存了下來，同時(shí)又保持了它的真正使命。ODBC 繼續(xù)以 OLE DB 的名稱和功能提供（或多或少地）開放式數(shù)據(jù)庫連接的功能。

OLE DB 作為一種編程接口，將 Microsoft 通用數(shù)據(jù)訪問 (UDA) 策略的理論概念應(yīng)用于實(shí)踐。UDA 能夠通過基于 COM 的單一編程接口來訪問各種類型的數(shù)據(jù)，包括關(guān)系型、非關(guān)系型和層次結(jié)構(gòu)型數(shù)據(jù)。

OLE DB 是作為一種組件技術(shù)而設(shè)計(jì)的，其特點(diǎn)是采用了多層模型。在 COM 橋的一側(cè)是用于保留數(shù)據(jù)的服務(wù)器組件，另一側(cè)則是了解如何連接和請(qǐng)求數(shù)據(jù)的客戶端組件。前者稱作 OLE DB 數(shù)據(jù)提供者；而后者則稱作 OLE DB 使用者。

使用者和提供者都是 COM 對(duì)象，并能夠通過一套 COM 接口互相通信。這種基于 COM 的通信可被概括為在抽象對(duì)象（如 DataSource、Session、Command 和 Rowset）上執(zhí)行的操作。因此，當(dāng)使用者連接到 DataSource，打開 Session，發(fā)出 Command，并返回?cái)?shù)據(jù) Rowset 時(shí)，便會(huì)出現(xiàn)這種情況。

ODBC 的這一進(jìn)化使 UDA 和 OLE DB 添加了一種功能，這種功能就像一個(gè)簡(jiǎn)單的關(guān)系表一樣，將所有的企業(yè)數(shù)據(jù)粘合在一起，不論它們是關(guān)系型、非關(guān)系型還是層次結(jié)構(gòu)型。

OLE DB 模型

說到數(shù)據(jù)訪問，我們有兩種基本選擇。一種是像 UDA 允許的那樣，采用通用數(shù)據(jù)訪問策略。另一種則傾向于使用通用數(shù)據(jù)結(jié)構(gòu)。它強(qiáng)行將現(xiàn)有的所有信息從當(dāng)前的數(shù)據(jù)存儲(chǔ)區(qū)移動(dòng)到一個(gè)能包容所有數(shù)據(jù)類型的數(shù)據(jù)庫服務(wù)器。

使用 OLE DB，需要將客戶所有的信息粘合在一起。另一種方式是，強(qiáng)行將客戶端升級(jí)至新的、更強(qiáng)大的、唯一的 DBMS，而這個(gè) DBMS 能夠處理任何格式的信息。

與 ODBC 相比，OLE DB 對(duì)數(shù)據(jù)物理結(jié)構(gòu)的依賴更少。此外，它不必嚴(yán)格基于 SQL。OLE DB 命令可以是 SQL 語句，也可以是其他的一些東西?？偟恼f來，可以將它們看作以任何能夠?yàn)槟繕?biāo)提供者理解的語法寫成的文本字符串。

像 ODBC 一樣, OLE DB 采用 C++ 的概念進(jìn)行設(shè)計(jì)，以盡可能提高中間層模塊數(shù)據(jù)訪問的性能。基于同樣的原因，OLE DB 不能直接在 Visual Basic® 或 ASP 中使用。

而不計(jì)其數(shù)的分布式系統(tǒng)卻是使用 Visual Basic 來生成組件的。這就是 Microsoft 引入 ActiveX® 數(shù)據(jù)對(duì)象 (ADO) 庫的主要原因。

ADO 的編程接口比原始的 OLE DB SDK 更加豐富。雖然在 C++ 應(yīng)用程序中使用 ADO 是完全可行的，但是 OLE DB 調(diào)用經(jīng)過的代碼層次較少，與相應(yīng)的 ADO 代碼相比，能更直接地到達(dá)數(shù)據(jù)。

雖然 ADO 很明顯是在 OLE DB 上生成的，但是調(diào)用原始 OLE DB 接口和通過 ADO 運(yùn)行時(shí)發(fā)出的調(diào)用具有不同的相對(duì)速度。這一事實(shí)導(dǎo)致了語言之間的差異。哪一種更好、更值得推薦呢？是 OLE DB 的 C++ 高性能層次還是 Visual Basic 組件中更簡(jiǎn)單、更友好的 ADO 模型？

除了提供者和使用者，OLE DB 模型還包括第三個(gè)元素——OLE DB 服務(wù)。服務(wù)是一種 COM 組件，用于處理返回給使用者的“行集”。它就像掛鉤一樣工作，監(jiān)督使用者和提供者之間的所有通信。ADO 在很大程度上依賴 OLE DB 服務(wù)來添加其擴(kuò)展功能，如數(shù)據(jù)塑型、持久性和斷開的記錄集。

因此，自從人們開始重視構(gòu)建基于 COM 的分布式應(yīng)用程序以來，就開發(fā)了各種針對(duì)某些特定領(lǐng)域的最佳實(shí)例。為改進(jìn) Web 應(yīng)用程序的可伸縮性，人們轉(zhuǎn)而使用數(shù)據(jù)訪問斷開模型。

簡(jiǎn)單說來，數(shù)據(jù)使用者和數(shù)據(jù)提供者并不總是連接的。一旦建立了連接，便可以發(fā)出指定的查詢，獲取記錄并將其放至內(nèi)存中的存儲(chǔ)庫，然后從數(shù)據(jù)源斷開連接。然后您再在脫機(jī)狀態(tài)下處理這些記錄，并在需要時(shí)重新連接或提交更改。這一模型不是在所有情況下都可以使用，不過，一旦它發(fā)生作用，您就會(huì)發(fā)現(xiàn)它在可伸縮性和總體性能方面非常有價(jià)值。

許多系統(tǒng)已經(jīng)進(jìn)行了轉(zhuǎn)換（或再轉(zhuǎn)換），通過客戶端游標(biāo)服務(wù)來部署 ADO 記錄集，從而啟用數(shù)據(jù)斷開。OLE DB 還不是專用于此類交互的模型，所以 ADO 是通過中間 OLE DB 服務(wù)進(jìn)行擴(kuò)展的。

由于其結(jié)構(gòu)所固有的靈活性，OLE DB 可以成功地應(yīng)用于斷開連接方案，但是，這當(dāng)然不代表最佳的工作方式。這一實(shí)現(xiàn)方案的另一小小的限制是：方案較多地依賴 ADO 記錄集進(jìn)行工作，以至于人們懷疑它不可能總是把每件事都做好。這樣的對(duì)象如何才能在各種情況下成為最快的工作工具，不論是連接還是斷開，有沒有 XML，是創(chuàng)建的還是從磁盤加載的？

此外，考慮到 ADO 的功能包與原始 OLE DB SDK 顯著不同，使用 OLE DB 將導(dǎo)致明顯的不一致現(xiàn)象。

因此，ADO.NET 成為數(shù)據(jù)訪問技術(shù)進(jìn)化中的下一步驟。不過，從名稱上看來，ADO.NET 似乎只是 ADO 的繼承者。.NET 中的 OLE DB 又是怎樣的？

.NET 托管提供者

永恒的進(jìn)化論規(guī)律現(xiàn)在將 OLE DB 技術(shù)向前推進(jìn)了一步，以滿足新用戶的要求。在 .NET 中，Web 應(yīng)用程序首先是一個(gè)斷開的應(yīng)用程序，它利用新設(shè)計(jì)的特殊工具來管理數(shù)據(jù)。

.NET 框架使得類能夠處理數(shù)據(jù)。這些類——特別是 ADO.NET 和 XML 名稱空間——可供收集、讀取和寫入。ADO.NET 和 XML 子系統(tǒng)最終取代了 ADO 和 OLE DB SDK?，F(xiàn)在，您擁有了一個(gè)唯一的、以語言為中心的方法來獲取和設(shè)置數(shù)據(jù)。

ADO.NET 類對(duì)數(shù)據(jù)源的抽象能力甚至比 ADO 還要好，因?yàn)樗鞔_設(shè)計(jì)為以數(shù)據(jù)為中心，而 ADO 中仍然使用以數(shù)據(jù)庫為中心的設(shè)計(jì)。

.NET 中對(duì)應(yīng)于 OLE DB 數(shù)據(jù)提供者的部分稱為“托管提供者”。它們的作用如下圖所示。

圖 1：托管提供者層次結(jié)構(gòu)圖

在 OLE DB 中可以按照相似性來識(shí)別兩個(gè)交互的層，即我上面提到的托管使用者層和托管提供者層。在處理數(shù)據(jù)時(shí)，.NET 應(yīng)用程序不必將特殊的類或組件作為使用者模塊使用。

如果 .NET 應(yīng)用程序只使用本機(jī)框架中的 DataSet 或 DataReader 對(duì)象，則其將立即成為“托管”數(shù)據(jù)使用者。要真正地獲取數(shù)據(jù)，應(yīng)使用從 DataSetCommand 和 DBCommand 中繼承的特殊類的實(shí)例。這些類代表了到數(shù)據(jù)源的鏈接。

你只需使用了解如何處理給定提供者的導(dǎo)出類，而不用指導(dǎo)通用對(duì)象來處理給定的提供者。所以出現(xiàn)的情況是，SQLDataSetCommand 將處理 SQL Server 數(shù)據(jù)庫，而 ADODataSetCommand 將包裝所有現(xiàn)有 OLE DB 提供者。

托管提供者將隱藏在這樣的 DataSetCommand 類中。你永遠(yuǎn)不會(huì)意識(shí)到它們的存在，也無需特意了解它們。只要使用類和設(shè)置屬性就可以了，這讓人感到愉快。

在這種情況下，上圖中的托管提供者層使用的交互模塊與 OLE DB 甚至更早的 ODBC 中使用的模塊沒有太大不同。使用者命令類針對(duì)的是包裝數(shù)據(jù)源的特定組件。它了解用于在源中讀寫數(shù)據(jù)行的協(xié)議。它還以一種 .NET 類能夠很好處理的格式返回結(jié)果。

為便于理解，讓我們回顧一下 OLE DB 和 .NET 數(shù)據(jù)檢索的共性。

OLE DB 提供者 .NET 托管提供者
標(biāo)識(shí) COM progID 包裝在命令類中
返回結(jié)果 Rowset 或 ADO Recordset DataSet 或 DataReader 類
更新方式 提供者的特殊命令 提供者的特殊命令
傳送格式 二進(jìn)制 XML

表 1：比較 OLE DB 和 .NET 數(shù)據(jù)提供者

目標(biāo)提供者是通過其位于 OLE DB 中的 COM progID 來識(shí)別的，而在 .NET 中，這些細(xì)節(jié)隱藏在訪問器類中。

OLE DB 提供者總是返回行集——COM 對(duì)象主要提供 IRowset 接口。如果通過 ADO 訪問數(shù)據(jù)，行集會(huì)轉(zhuǎn)換為更豐富和更腳本化的對(duì)象，稱作記錄集。

.NET 應(yīng)用程序只使用具有不同功能的各種類。DataReader 類是一個(gè)簡(jiǎn)單、快捷、只能前進(jìn)的游標(biāo)，在連接狀態(tài)下工作并按記錄來提供訪問。結(jié)束后必須顯式斷開連接。相反，DataSet 對(duì)象是內(nèi)存中的斷開連接集合表。它是 DataSetCommand 類的填充的實(shí)例。DataSet 對(duì)象的內(nèi)容建立在 DataSetCommand 從數(shù)據(jù)源取回的 XML 流的基礎(chǔ)上。

我將在以后的專欄中講述有關(guān) DataReader 和 DataSet 的內(nèi)容。

數(shù)據(jù)以二進(jìn)制格式從提供者到達(dá)使用者，如果部署了 OLE DB，則還會(huì)經(jīng)過 COM 配置。而在 .NET 中，托管提供者將返回一個(gè) XML 流。

兩種提供者都支持查詢語言（通常是 SQL 和各個(gè)供應(yīng)商特有的擴(kuò)展）。通過該語言可以執(zhí)行更新和詢問數(shù)據(jù)源。

那么，OLE DB 數(shù)據(jù)提供者和 .NET 數(shù)據(jù)提供者之間的區(qū)別是什么呢？抽象地說，它們使用相同的數(shù)據(jù)訪問策略。但是托管提供者更加簡(jiǎn)單和專業(yè)。兩個(gè)主要的原因?qū)е铝似湫阅艿膬?yōu)越性。首先，托管提供者不使用 COM 互操作橋來獲取和設(shè)置數(shù)據(jù)。作為 COM 組件，OLE DB 提供者在這一點(diǎn)上別無選擇。其次，托管提供者通常利用來自供應(yīng)商的內(nèi)部數(shù)據(jù)源知識(shí)來更快地獲取和設(shè)置行。OLE DB 提供者也是這樣做的，但是當(dāng)在 .NET 內(nèi)部使用時(shí)，OLE DB 提供者必須為其基于 COM 的特性付出代價(jià)，并且需要額外的代碼將數(shù)據(jù)轉(zhuǎn)換為 .NET 特有的類。

現(xiàn)有的托管提供者

像在 Beta 1 中一樣，NET 框架的特色是具有兩個(gè)托管提供者：一個(gè)用于 SQL Server（7.0 版本或更高），一個(gè)用于所有能夠通過 OLE DB 提供者獲得的數(shù)據(jù)源。

SQL Server 托管提供者隱藏在特定的類（如 SQL DataReader、SQL DataSetCommand 和 SQLCommand）后。這些類直接訪問低層的 SQL Server 文件系統(tǒng)。下圖是提供者的類圖。該圖將以前的通用架構(gòu)映射至 SQL Server 托管提供者。

圖 2：SQL Server 托管提供者的類圖

OLE DB 托管提供者在 .NET 中的作用與 ODBC OLE DB 提供者在 Windows DNA 系統(tǒng)中的作用是相同的。簡(jiǎn)單說，它體現(xiàn)了后向兼容性，也反映了這樣一個(gè)事實(shí)，即所有 .NET 應(yīng)用程序均可以面向任何以 OLE DB 為基礎(chǔ)的現(xiàn)有數(shù)據(jù)源。OLE DB 托管提供者的類圖如下所示。

圖 3：OLE DB 托管提供者的類圖

請(qǐng)注意在 Beta 2 中，ADOxxx 類需要重命名為 OleDbxxx。

OLE DB 托管提供者將 .NET 類提供給調(diào)用方，但利用指定的 OLE DB 提供者來獲取行。.NET 應(yīng)用程序與底層 OLE DB 提供者（COM 對(duì)象）之間的通信通過 COM 互操作橋發(fā)生。

總的來說，在 .NET 中通過上述兩個(gè)提供者均可以訪問 SQL Server 7.0（及更高版本）的表。SQL Server 的托管提供者直接從 DBMS 文件系統(tǒng)請(qǐng)求數(shù)據(jù)，而 OLE DB 托管提供者依賴 SQLOLEDB OLE DB 提供者的服務(wù)，從而導(dǎo)致需要經(jīng)過額外層次的代碼。

現(xiàn)在，如果你面對(duì)的是 SQL Server 以外的任何數(shù)據(jù)源，那么 OLE DB 托管提供者是唯一的通道。通過同一通道，你還可以到達(dá)任何 ODBC 數(shù)據(jù)源。

OLE DB 托管提供者是在 COM 互操作橋上生成的瘦包裝，可以調(diào)入本地 OLE DB 提供者。除了設(shè)置和終止調(diào)用，這一模塊還負(fù)責(zé)將返回的行集包裝至 DataSet 或 ADO DataReader 對(duì)象，以便進(jìn)行后續(xù) .NET 處理。

在 .NET 代碼層，通過本地托管提供者或 OLE DB 提供者訪問 SQL Server 表實(shí)際是對(duì)涉及到的類的前綴進(jìn)行更改。以下是用于 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 托管提供者代表了數(shù)據(jù)訪問技術(shù)演化的下一步發(fā)展方向，但是，在 Beta 1 中還沒有文檔化的 SDK 涉及數(shù)據(jù)源特定的托管提供者。幾個(gè)關(guān)于 OLE DB 和 .NET 的基本問題是無法忽略的。它們正在等待著 Beta 2。

難道為 OLE DB 開發(fā)的所有代碼只是過時(shí)的代碼嗎？公司已經(jīng)投入（而且經(jīng)常是仍然在投入）的為自己的數(shù)據(jù)編寫提供者的一切努力將會(huì)如何？

堅(jiān)守你的信念——OLE DB 不是一項(xiàng)消亡的技術(shù)。尤其是對(duì)于功能豐富、通用并且獨(dú)立于 .NET 的編程接口，它仍然是基本的規(guī)范。它不專門針對(duì) .NET，但它獲得了很好的支持。

這就是說，如果要公開自定義數(shù)據(jù)，就不能忽略 .NET 和托管提供者的出現(xiàn)。那么，什么是包裝數(shù)據(jù)提供者的最佳接口呢？你應(yīng)該怎樣計(jì)劃盡快公開你的數(shù)據(jù)呢？例如，從下個(gè)星期一上午 8 點(diǎn)開始？

.NET 使用開放的標(biāo)準(zhǔn)并廣泛地基于 XML。在這種情況下，如果你需要公開擁有所有權(quán)而又基于文本的數(shù)據(jù)，則只需要考慮使用 XML（可能是自定義方案）來發(fā)布。在 .NET 中有這么多的工具可與 XML 數(shù)據(jù)配合工作，包裝類的生成應(yīng)該完全沒有問題。

對(duì)于更復(fù)雜的數(shù)據(jù)存儲(chǔ)，OLE DB 提供者仍是有意義的，因?yàn)槟愕挠脩羧焊螅铱赡懿粌H僅局限于 .NET。對(duì)于 .NET 專有的應(yīng)用程序，托管提供者當(dāng)然可以提供巨大的性能優(yōu)勢(shì)，但我對(duì)此持非常謹(jǐn)慎的態(tài)度——尤其是要在這樣短的時(shí)間內(nèi)做出決定！不要忘記，目前為止還沒有發(fā)布有關(guān)托管提供者的任何 SDK，盡管 Microsoft 已經(jīng)做出了這樣的承諾。

總之，這個(gè)星期一早晨我將要開始編寫的下一個(gè)數(shù)據(jù)提供者將會(huì)包括一對(duì) OLE DB 數(shù)據(jù)提供者和一個(gè)使用 XML 的 .NET 包裝類。我的首要選擇不會(huì)是用 .NET 類通過 COM Interop 來包裝 OLE DB 提供者。我寧可使用同樣的、經(jīng)過一定調(diào)整的源代碼。在這種情況下，托管 C++ 很可能是便于重用“物理”代碼的最佳語言。

OLE DB 的結(jié)局

讓我們將此作為一種預(yù)言，留待從現(xiàn)在開始的未來幾年驗(yàn)證。我要冒昧地說，OLE DB 將與 SGML（標(biāo)準(zhǔn)通用標(biāo)記語言，XML 的前身）一樣，其最終結(jié)局不會(huì)很理想。

作為數(shù)據(jù)交換世界的救世主而引進(jìn)的 SGML 從來沒有成為事實(shí)上的標(biāo)準(zhǔn)，也許是因?yàn)閷?duì)于日常使用來說它太過強(qiáng)大和復(fù)雜了。事實(shí)是，它令人激動(dòng)的原理經(jīng)過了適當(dāng)?shù)目s減和特殊化，并生成 XML，然后才被廣泛地接受。

我的預(yù)言是，一旦 .NET 穩(wěn)固了其基礎(chǔ)，OLE DB 將逐漸喪失其重要性，直至最終消失。我不能確定這一過程將會(huì)持續(xù)多長(zhǎng)時(shí)間，但我確信這一點(diǎn)。

論據(jù)就在后面 。不要走開。

對(duì)話：是的，現(xiàn)在我覺得過時(shí)了

你很可能生活在另一個(gè)時(shí)空！你該如何將現(xiàn)有的 ADO 代碼定義為陳舊代碼（在大多數(shù)情況下，這些代碼是在六個(gè)月內(nèi)寫成的。）？以 .NET 技術(shù)/平臺(tái)的名義？它甚至還沒有進(jìn)入 Beta 程序的第二階段。

沒有任何重點(diǎn)的生活是什么樣子的？無論如何，這個(gè)問題問得好。

面對(duì)近來許多 DNA 系統(tǒng)中的 ADO 代碼，我們能夠?qū)⑺鼈兌x為陳舊的代碼嗎？我的答案仍是：“是的，我們會(huì)?！钡俏掖_實(shí)理解，這聽起來實(shí)在令人迷惑。

我認(rèn)為，“陳舊代碼”就是不再適合宿主平臺(tái)核心的代碼。相信我，這的確是 .NET“即將”面對(duì)的狀況。當(dāng)然，還是有方法在 .NET 中將現(xiàn)有代碼、組件和應(yīng)用程序結(jié)合起來的。

.NET 是一場(chǎng)非暴力革命，在未來的幾年中，它將吸取 Windows 軟件中的任何有生命力的實(shí)例。反抗是徒勞的——你注定會(huì)被同化。無論代碼的年齡如何，在我對(duì)“陳舊”的定義中，真正重要的是源代碼與運(yùn)行時(shí)的一致性。

.NET 改變了 Windows 運(yùn)行時(shí)，使其被托管。雖然 COM 和 Windows SDK 還沒有完全喪失生命力，但你必須根據(jù)另一個(gè)模型來編寫代碼。不管這一新的運(yùn)行時(shí)的基礎(chǔ)是什么，一種嶄新的模型將會(huì)與舊模型展開競(jìng)爭(zhēng)。這一新模型將是未來 Windows 的模型。

Windows 不會(huì)滅亡，但是它將改變。COM 不會(huì)滅亡，但它將不得不面對(duì) .NET 類。ADO 不會(huì)滅亡并將繼續(xù)發(fā)揮作用，但是以 ADO.NET 為特點(diǎn)的 .NET 才是 ADO 的未來。

.NET 并不簡(jiǎn)單的就是 Windows 6.0，ADO.NET 也不是以前稱作 ADO 3.0 的奇妙新名字。它是不同的，又是普遍適用的。它是新的平臺(tái)。其他的內(nèi)容或者是另一個(gè)平臺(tái)，或者是陳舊的代碼（當(dāng)集成在一起時(shí)）。

陳舊代碼是不論存在時(shí)間的。我知道人們還是會(huì)編寫 DNA 系統(tǒng)，在這一周，在六個(gè)月內(nèi)，甚至在 .NET 發(fā)布后。我并不是說這是完全錯(cuò)誤或是應(yīng)該絕對(duì)避免的。只是要提醒你，你正在逆潮流而動(dòng)。