作者說明去年此時，microsoft 邀請我撰寫一篇文章，目的是幫助基于 com 的 ado 開發人員理解將數據訪問代碼移植到 .net 的機制和問題。今年，他們希望我更新這篇文章，并在其中加入有關 ado 2.0 的信息。由于目前我正忙于 hitchhiker's guide 一書的新版工作，因此僅摘錄新章片段，以饗讀者。hitchhiker's guide to visual studio and sql server 2005 (7th edition)將在 whidbey 和 yukon 發布后由 addison wesley 出版發行。

感謝 calvin、hobbes 和 bill waterson。一段時間以來，我一直著迷于術語“變形”。此項技術（顯然）已經風靡一時，而且據稱用于描述青蛙變王子或木偶變成人（反之亦然）的過程。但是，本文使用的變形是指 visual basic 6.0 ado 代碼的轉換過程，轉換后的代碼能夠用于 .net 應用程序以執行大致相同的操作。變形意味著轉換結果只能根據原始來源辨認 — 在這種情況下，假定您將基于 com 的 ado 代碼（從 visual basic 6.0）轉換為 ado.net 是完全適當的。不過，一些人認為這種情況發生的可能性不大，對此我不敢茍同，謹以本文追本溯源。

為什么需要進行遷移？

一個天氣晴朗的下午，我在屋后的草坪上修好了三速自行車，父親提醒我不應該修理沒有損壞的零件。我舉雙手贊成。除非有迫不得已的原因需要修改功能性代碼，并且在之前進行了合理的成本-收益分析，否則這樣做毫無意義。用“合理”這個詞的意思是，不以兜售情感的誘惑（這種誘惑可能來自于您的首席程序員，也可能來自于您配偶的親戚）為轉移、同時考慮到各種費用的全面分析，這些費用包括設計、開發、測試、部署和支持應用程序，以及對開發人員、支持團隊和客戶的重新培訓的支出。為了運行該框架和新的應用程序，您可能還需要進行硬件升級，這筆費用也是要考慮的因素之一。眾所周知，轉換代碼或者哪怕只是調整一下，開支也是很昂貴的。即使您小心翼翼，每一行更改的代碼還是可能帶來嚴重的后果和副作用（盡管通常是無意的）。盡管如此，還是存在轉換現有代碼的充足合理原因，例如：

我不打算探究從現有代碼基向新技術的誘人前景前進的決策過程。我將它留給您的 it 人員。如果您閱讀本文的目的是為了掌握轉換基于 com 的現有 ado 代碼（我稱其為“ado 經典”或 adoc）的機制，以使其在 visual basic .net 應用程序中運行，那么請繼續。

我們是如何走到這一步的？

microsoft 引入的數據訪問接口歷經了年復一年的更迭。起初，這些接口是為了訪問特定版本的連接性引擎技術（joint engine technology，jet）dbms 和 sql server（通過 db-library）而專門設計的。隨著這項技術的不斷成熟，其他“繼承”接口或通用型（one-size-fits-all，osfa）接口（如 odbc 和 ole db）生來就可以訪問幾乎所有的數據源。創建基于 com 的 ado（我稱其為 adoc）是為了方便訪問 ole db。

ado“經典”的進演

時間流轉，adoc 不斷發展并且其后來的 8 個版本也廣泛應用，并集成到基于 com 的 visual basic 中。adoc 開發人員也學會了如何構建管理各種規模數據庫的應用程序，并將其應用到世界各地的客戶端/服務器、中間層和 asp 體系架構中。adoc 還支持存儲過程（包括完整的 io 參數管理）、自動的 update 查詢生成、異步操作、客戶端和服務器端游標、ro/fo 數據流等，因此為人們所普遍接受。但是，基于 com 的 ado 還存在一些問題。它對 mdac 堆棧的依賴使其容易發生 dll hell 問題 — 有時，部署的應用程序在升級 mdac 時會失敗。

引入 ado.net

為了解決必須替換服務應用程序組件的問題，microsoft 創造了 .net framework。除此之外，microsoft 還創建了一個全新的數據訪問接口 — ado.net。在創造 ado.net 過程初期，microsoft 開發人員將新的數據訪問接口稱為“xdo”。這是由于這個新的數據訪問范例是通過 xml 置入接口的，因此它能夠讀取 xml 文件以填充其對象，或者根據需要延伸 xml 以將數據和架構傳遞到其他層。因此，這個名字意義深刻。然而，microsoft 認為如果創建另一個數據訪問接口，開發人員將不知所措，甚至惱怒不休，所以將其命名為“ado.net”。當然，adoc 和 ado.net 在更高層次上的功能相同。不過，這兩者在后臺的工作原理 迥然不同，而且依我看來，大部分都是很出色的。

ado.net 首次面世時，缺少很多現在看來成熟的 adoc 所支持的基本功能。這些基本功能包括：批文件更新、異步操作、服務器端游標、運行時操作命令生成等。有些人認為，ado.net 是為了用于 asp.net 而設計的，客戶端/服務器應用程序沒有必要使用它，但是 microsoft 堅信斷開連接的 dataset 能夠使客戶端/服務器應用程序更高效，并使其脫離對難以擴展的設計（這些設計依賴于服務器端狀態管理）的依賴。正是由于該邏輯，ado.net 不包含對服務器端游標的支持。這個新思路的核心是“斷開連接的”客戶端數據存儲，您可以根據需要輕松地將其保留并序列化為 xml，以便傳遞到其他層。它也非常適用于 microsoft 的新 xml web services — 面向服務的體系結構 (soa) 計劃。注意，用于保留 adoc recordset 的 xml 與 ado.net 預期的 xml 格式不兼容。（請參閱 much ado about data: doing the impossible (again)。）microsoft 還認為，最好允許開發人員構建自己的 sql 操作命令（update、insert、delete）或通過向導構建，而不是依賴屬性驅動的 adoc update 方法代碼，因為在嘗試搞清楚如何更改 recordset 時，該代碼經常出錯。當然，在一些簡單的情況下，這些代碼也能夠實現 commandbuilder 以自動構建操作命令，但是正如本文所述，我認為您不會采取這種方法。（請參閱 weaning developers from the commandbuilder。）的確，這些問題不是沒有解決的方法，但是額外的開銷會進一步阻礙人們進行遷移，或者使遷移過程難上加難。

解決疑難

另一方面，microsoft 允許開發人員編寫托管接口，直接解決了有關 osfa 的問題。即 ado.net 公開了一個專用于 microsoft sql server (sqlclient) 以及其他數據庫（包括 oracle 和 db2）的 .net 數據提供程序。這意味著，數據提供程序引擎能夠利用 dbms 的所有功能，并以最低的級別與數據庫通訊。自 dblibrary 以來，ado.net 第一次能夠通過表格數據流 (tds) — 它是低級協議，與 sql server 進行交互。這意味著，sqlclient 提供程序能夠訪問所有 sql server 功能，并了解這些功能之間的細微差別，從而使應用程序也就如虎添翼。對于開發人員而言，不存在將一種 dbms 代碼轉換為另一種代碼的問題，因為本地接口與 oledb 和 odbc .net 數據提供程序實現的 .net osfa 接口類似。

ado.net 還公開 dblibrary 的另一個功能 — 直接訪問低級數據接口返回的數據流。這個接口在建立連接時以只進、一次一行的方式將您的代碼鏈接到查詢返回的輸入數據，它作為 datareader 實現。ado.net 中的所有方法都使用 datareader 直接或在后臺獲取結果集。這意味著，應用程序能夠更快地獲取數據并更好地控制這個過程。

遷移 ado 經典代碼的開發技巧

在很大程度上，大多數應用程序中的數據訪問邏輯都可以分為幾個部分：

ado 開發人員將發現，他們能夠以類似的方式分解和編寫 ado.net 代碼。但是，每部分都有差別，起初這有點令人沮喪，不過，只要單獨處理就能夠得心應手。visual basic 6.0 轉換向導并不會將 adoc 代碼轉化為 ado.net — 這是癡人說夢，因為 ado.net 采用的編程方法與 adoc 不同。例如，如果使用 adoc 中的 shape 語法來管理層次結構，您會發現 .net framework 不支持 shape，但是卻支持通過 dataset 類管理多個相關的行集合，一個 dataset 類可以包含多個 datatable 對象，每個 datatable 對象包含一個獨立的行集合。

每個 .net 數據提供程序都負責實現符合自己“風格”的 ado.net 類。它們都支持一組使用（大致）相同的屬性和設置的“核心”操作。當然，每個 .net 數據提供程序還支持各自的 sql 變體和 connectionstring 設置。例如，sqlclient 提供程序（用于 microsoft sql server）可實現 sqlconnection、sqlcommand、sqldataadapter 和 sqldatareader，而 oledb 提供程序還支持 oledbconnection、oledbcommand 等。在我撰寫的書籍中，這些對象是根據功能來引用的 — 例如，sqlcommand 就稱為“命令”類。

ado.net connection (sqlconnection) 類與 adoc connection 對象類似，但是它接受一個不同（但熟悉）的 connectionstring。它不能以異步方式開啟，但是在執行 fill 和 update 方法時，它能夠由 dataadapter 自動管理。在 ado.net 中，不能直接針對 connection 對象執行 sql — 需要構建一條命令來完成這項操作。您還要修改連接錯誤處理程序，以使其預料到在嘗試 adoc 連接時發生的同一類問題。請注意，adoc 使用的連接池機制與 ado.net 大致相同，但是通過 ado.net 管理池選項和狀態更容易。

ado.net command 類與 adoc command 對象類似，但是在這種情況下，必須構建一個 command 對象來執行 sql 或運行存儲過程。ado.net command 對象公開的方法與 adoc 的方法有天壤之別。與 adoc 不同，您可以訪問一個新的低級接口 — datareader (sqldatareader)，該接口公開一個高速原始數據流，用于返回查詢數據。command 類支持的 parameters 集合與 adoc 中使用的 parameters 集合類似。請注意，ado.net 中的 sql 參數標記方式有所不同。

您還會發現，ado.net datatable 與 adoc recordset 大致等效。雖然它不是作為游標進行管理，但是通過它存儲和管理返回的行集合更有效。定位到特定行與數組尋址一樣容易。通過 dataset，還可以一次管理來自不同數據源的多個行集合。這個類用于管理一個或多個 datatable 對象以及這些對象包含的行集合。您能夠編寫這些行集合（即使它們來自分散的源）之間的關系代碼，以及根據您定義的父子關系輕松地進行定位、篩選和搜索。

數據綁定也發生了變化。不用研究 visual basic 6.0 數據綁定的繁文縟節，只要在代碼中使用拖放生成的代碼或設置數據綁定鏈接，您就能夠更輕松地綁定到行集合。ado.net 2.0 對數據綁定范例的精益求精使得這個過程更加簡單。

對 adoc recordset 進行尋址的開銷很大，因為所有列都是作為 variant 返回的。ado.net 能夠利用強類型的 datatable 和 dataset，因此進行對象尋址是小菜一碟。這意味著，數據以原始類型存儲和管理 — 即，整數存儲為整型，字符串存儲為字符串。您可能還會注意到，強類型操作是更快的指令。我們還鼓勵您在開發環境中使用“option strict on”和“option explicit on”選項。雖然這意味著代碼必須顯式強制變量（通過代碼轉換類型），但得到的代碼將更穩定，以便在意外數據到達時不會像往常一樣失敗。

為了使管理表格更新更輕松，ado.net dataadapter 模仿了 visual basic 6.0 數據對象向導 (dow)。這個類允許定義自己的 update、insert 和 delete sql — 一個特殊的 sql 查詢或存儲過程。這使得 ado.net 更加輕巧，但是代碼要承擔生成這些命令的責任 — ado.net 不再像 adoc 那樣在運行時嘗試生成這些命令。后面我們將看到，ado.net 2.0 重新引入了批文件更新和異步操作來提升性能。

與 adoc 一樣，異常處理也是 ado.net 設計的一個重要部分。幸運的是，.net framework 支持 try/catch 異常管理，與您熟悉的傳統 visual basic 6.0“on error”例程相比，它的功能更強大而且更靈活。這種異常管理方法允許您將那些以數據為中心的特定異常從其他問題導致的異常中篩選出來。這使編寫異常處理程序更簡單，并使應用程序意外失敗的可能性更小。

ado.net 2.0 有哪些新功能？

ado.net 2.0 的最新版本填補了一些遷移 adoc 時遺留的空白，并實現了一些聞所未聞的功能。這些創新允許您生成更安全、更健壯、速度更快的代碼 — 特別是 windows 窗體（客戶端/服務器）應用程序。這些升級包括：

whidbey 集成

ado 集成到 visual basic 和 visual studio 已經有一段時間了。但是，visual studio 2005 團隊這次在集成級別上進展地更加深入了一些。雖然不會看到創建熟悉的 dataadapter 的向導，但是您將看到拖放技術，它們可以生成許多熟悉的和新的強類型數據結構。請記住，當您希望 rad 接口生成代碼時（特別是在簡單的情況下），這些工具最有趣。microsoft 聲稱他們還為支持 n 層開發做了大量工作。您可以創建在同一個程序集內生成 dataset 的應用程序，也可以創建在引用的程序集中訪問數據集以及自己的對象的應用程序。當設計變得較復雜時，這些工具可以公開您自己生成的中間層業務對象。有關該集成的討論超出了本文的范圍，但是在我的書籍中將涉及到這一點。

替代方案是什么？

對于任何一種軟件解決方案來說，都有一打替代解決方案 — 在完成一個解決方案后，總是有人能夠就每一處指出一打替代方法。當然，每種方法都各有利弊。本文，我們將重點討論數據訪問接口的問題，并將其余的轉換任務留給其他人。當然，您的數據訪問代碼或許沒那么容易隔離。雖然迄今為止，大多數業界學者以及我本人已經談論 3 層（或“n”層）設計幾十年了，但并不是每個人都采納我們的建議。如果您創建的應用程序帶有一組處理數據的獨立中間層對象，那么轉換這些對象以支持 ado.net 的任務將非常簡單。但是，如果您的代碼零碎不堪，就像我多年以來審查的“意大利面條”代碼，那么要將 adoc 例程從應用程序的結構中清除而不使應用程序土崩瓦解，您可能會經歷一段備受煎熬的過程 — 就好比在早春時節里，一邊與俄羅斯狼犬格斗，一邊試著拔掉它身上的狗毛。下面我們看一下替代方法 — 其中一定有一種方法對您和您的技巧有幫助。

主要考慮事項

在大刀闊斧地開展轉換過程以前，您需要考慮著手點，并詢問以下問題：“我能夠克服所有艱難險阻來實現轉換嗎？”請考慮以下影響轉換過程的因素：

小結

是的，ado“經典”代碼可以變為 ado.net。實現過程像看起來那樣難嗎？我對此置疑。一旦理解 ado.net 是一個全新（且更好）的數據訪問接口而不是 adoc，您就會對轉換過程更滿意。并不是所有的應用程序都需要轉換。我前面說過，如果零件沒壞就不需要修理。我希望這對您有所幫助。如果您需要更多幫助，這里有幾本書能夠派上用場。無論如何，我希望本文能夠助您一臂之力。

相關書籍

ado.net and ado examples and best practices for vb programmers

ado.net examples and best practices for c# programmers

1. 變形 (tràns-mòg´re-fì´, trànz-)，及物動詞。變為另一種形狀或格式，特別是稀奇古怪的形式。
(the american heritage dictionary of the english language, third edition)