從 ADO“經典”遷移到 ADO.NET

來源:互聯網
上載者:User
ado

本文摘自 Hitchhiker's Guide to Visual Studio and SQL Server 2005(7th Edition)

William Vaughn
Beta V Corporation

適用於
Microsoft ADO.NET
Microsoft SQL Server 2005(代號“Yukon”)
Microsoft Visual Studio 2005(代號“Whidbey”)

摘要:Bill Vaughn 討論了 Visual Basic 6.0 ADO 代碼的轉換過程,轉換後的代碼能夠用於 .NET 應用程式以執行大致相同的操作。

作者說明去年此時,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 是完全適當的。不過,一些人認為這種情況發生的可能性不大,對此我不敢苟同,謹以本文追本溯源。

為什麼需要進行遷移?

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

也許現有代碼無法利用硬體或 OS 方面的改進。例如,也許代碼是設計為與(而且可能僅與)Windows 9x 一起工作,而客戶已經升級到 Windows XP。

也許現有代碼的競爭力不如其他公司編寫的代碼,後者的應用程式速度更快、更可靠,並且銷售份額更大。這樣的事情屢屢發生,因為客戶總是力爭在功能、特性、和有競爭力的價格方面保持領先。

也許新的應用程式伸縮性更好、能夠支援更多的使用者、更安全、更易於部署,或者輕鬆實現了現有技術所不具備的功能。

也許客戶抱怨代碼似乎工作一段時間後就會死機 — 特別是在安裝了其他一些軟體之後。

也許(可能最重要的是)您發現新的開發平台能夠提高建立新應用程式,支援代碼以及使用該平台的小規模使用者的能力。

我不打算探究從現有代碼基向新技術的誘人前景前進的決策過程。我將它留給您的 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 資料結構管理更新、插入和刪除操作。這些常式還管理並發衝突、批處理操作和事務。

管理異常:所有這些常式都有例外處理常式,負責處理在建立串連、準備並執行查詢或將資料分發到伺服器時出現的常見問題。

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 表單(用戶端/伺服器)應用程式。這些升級包括:

沒有 MDAC 依賴。ADO.NET 的早期版本通常要求升級 MDAC 堆棧(包括運行 ADOc 應用程式所需的 DLL),而 ADO.NET 2.0 在使用 SqlClient 時終止了這種依賴性。MDAC 的早期版本 (2.6-2.9) 能夠滿足 OleDb 和 Odbc .NET 資料提供者。這意味著,安裝 .NET 應用程式的破壞性較小,因為它不會影響現有的 ADOc 應用程式。

非同步作業。雖然 ADO.NET 2.0 不能像 ADOc 那樣以非同步方式開啟串連,但是它能夠非同步地執行 DataReader 命令。這意味著,您能夠編寫代碼,以便在執行查詢期間為使用者呈現一個進度條,或者在應用程式線程上執行其他工作,並根據進度返回狀態事件。

多活動結果集 (MARS)。在 ADO 2.0 之前,我們不能使用一個串連執行多個操作。但是 MARS 可以在同一個串連上支援多個操作。這意味著,在同時讀取和更新行時,不必開啟多個串連。當然,這要假定 .NET 資料提供者和目標 DBMS 支援這個功能。

批處理。ADOc 支援在一個往返行程中將多個操作命令發送到伺服器的功能。這個功能在 ADO.NET 2.0 中重新實現了。通過批執行 Update 方法操作,應用程式的變更速度更快,並且與伺服器之間的往返行程更少(更廉價)。

BCP 支援。在將資料移出外部資料源或產生的資料來源時,使用批量複製工具 + 生產力 (BCP) 代替傳統的 ADO.NET 方法很重要。ADO.NET 2.0 現在包含一個 BCP 類,以允許直接存取這個高速的資料上傳功能。在傳統 ADO 方法所需的一部分時間內,這種方法就可以完成批量資料轉送。

DataSet 公開為 DataReader。為了使在層與層之間公開資料更方便,現在可以建立一個 DataSet(或 DataTable),並將該資料集作為 DataReader 傳遞到另一個層。您也可以直接從 DataReader 載入 DataTable。

DataSet 序列化。在早期版本中,可以使用 Remoting 在各層之間傳遞 DataSet,但是資料是以 XML 格式傳遞的。在 ADO.NET 2.0 中,可以將 DataSet 序列化為二進位格式。這意味著層間效能的急劇增長,但是要使用 Microsoft 的專用格式來傳輸資料。另一個選項 (SchemaSerializationMode=TypedDataSet) 能夠去除資料流中的架構,從而減少傳輸的資料量,同時仍然適用於跨平台的情況。

Yukon 支援。ADO.NET 2.0 首次可以支援本地 SQL Server 2000 資料類型,還可能支援基於 CLR 的使用者定義型別。這些資料類型包括 varchar(max)、nvarchar(max)、varbinary(max) 和新的 XML 類型。

新的公用基類。為更輕鬆地編寫跨平台 app程式,ADO.NET 2.0 公開了一個 DB* 基類。例如,公開 DbConnection、DbCommand 和 DbDataAdapter。這些類仍然要求使用特定於提供者的 SQL 文法,但是通過它們可以編寫出能夠訪問多個不同資料來源的應用程式。

伺服器和提供者枚舉。這些新類允許您探索 .NET 資料提供者提供的功能,以及應用程式可見的伺服器和執行個體。在編寫管理工具、啟動/停止/暫停伺服器或只是確定伺服器狀態時,這些類非常有用。請注意,除了 SQL-DMO,SQL Server 現在還公開了 SMO 來管理 SQL Server 執行個體。

新的計數器。SqlClient 提供者在 .NET 的早期版本中公開了許多計數器,但是它們都不太可靠。這些新的計數器將更精確,並且能夠確定串連池機制的狀態。

串連池管理。ADO .NET 2.0 不但允許您清除一個或所有的池,而且還允許清除管理池行為的其他功能,而早期版本僅允許您選擇串連池選項。改進的串連池機制還能協助您檢測壞池 — 串連到不可用伺服器的池。

Whidbey 整合

ADO 整合到 Visual Basic 和 Visual Studio 已經有一段時間了。但是,Visual Studio 2005 團隊這次在整合層級上進展地更加深入了一些。雖然不會看到建立熟悉的 DataAdapter 的嚮導,但是您將看到拖放技術,它們可以產生許多熟悉的和新的強型別資料結構。請記住,當您希望 RAD 介面產生代碼時(特別是在簡單的情況下),這些工具最有趣。Microsoft 聲稱他們還為支援 N 層開發做了大量工作。您可以建立在同一個程式集內產生 DataSet 的應用程式,也可以建立在引用的程式集中訪問資料集以及自己的對象的應用程式。當設計變得較複雜時,這些工具可以公開您自己產生的中介層業務對象。有關該整合的討論超出了本文的範圍,但是在我的書籍中將涉及到這一點。

替代方案是什嗎?

對於任何一種軟體解決方案來說,都有一打替代解決方案 — 在完成一個解決方案後,總是有人能夠就每一處指出一打替代方法。當然,每種方法都各有利弊。本文,我們將重點討論資料提供者的問題,並將其餘的轉換任務留給其他人。當然,您的資料存取碼或許沒那麼容易隔離。雖然迄今為止,大多數業界學者以及我本人已經談論 3 層(或“N”層)設計幾十年了,但並不是每個人都採納我們的建議。如果您建立的應用程式帶有一組處理資料的獨立中介層對象,那麼轉換這些對象以支援 ADO.NET 的任務將非常簡單。但是,如果您的代碼零碎不堪,就像我多年以來審查的“意大利麵條”代碼,那麼要將 ADOc 常式從應用程式的結構中清除而不使應用程式土崩瓦解,您可能會經曆一段備受煎熬的過程 — 就好比在早春時節裡,一邊與俄羅斯狼犬格鬥,一邊試著拔掉它身上的狗毛。下面我們看一下替代方法 — 其中一定有一種方法對您和您的技巧有協助。

通過 Visual Basic 6.0 匯入項目嚮導將您的項目轉換為 ADO.NET 項目。據說新的 Visual Studio 2005 轉換嚮導比以往的嚮導更加智能,但是它仍然不能將 ADOc 代碼轉換為 ADO.NET。雖然在較大且較為複雜的項目中應用它可能還需要一段時間,但是對於較簡單的項目而言,實現轉換應該是一帆風順的。轉換後,您將得到變換並封裝在 COM interop 層中的 ADOc 代碼,以便它能夠在新的 Visual Basic .NET 項目中編譯,並(與註冊後的 MDAC 版本一起)部署和運行在目標系統上。這還意味著,您需要注意編碼技巧(有一些晚期綁定技巧變形效果不太好),我在去年這個時候撰寫的那篇文章中討論過這些技巧。

另一個可行的方法是訪問每個 ADOc 代碼區段,並按邏輯將其分解。想像一下,如果通過一個中斷連線的 DataSet 就能完成任務,或者任務僅使用 DataReader 來返回行 — 這類似於預設的“消防栓”Recordset。在這種情況下,轉換到 ADO.NET 是一種既簡單又乾淨的過程。在處理伺服器端遊標(在用戶端/伺服器應用程式中特別常見)時,您需要決定重新設計代碼以使用中斷連線的 DataSet 的策略,或者考慮使用 ANSI CURSOR 操作符管理自己建立的伺服器端遊標類。在很多情況下,進行一些設計上的更改會消除對伺服器端遊標的需要。但是,這可能不符合實際情況,因此請三思而行。

如果您在中介層組件中分離了 ADOc 代碼,那麼第三種方法將特別有用。在這種情況下,“只需”建立返回類似結構的組件的 ADO.NET 版本即可替換 ADOc 代碼 — 假定組件使用者不將 ADOc Recordset 返回到其他層。如果您公開一個自訂業務對象類,則通過 Visual Studio 2005 中的工具將其變形為基於 ADO.NET 的資料訪問組件將易如反掌。

主要考慮事項

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

您從哪種類型的體繫結構進行遷移?如果從 ASP 編程體系遷移,則 ASP.NET 方法將十分強大,並且管理 ADO 對象的方式也迥然不同。您會喜歡這種新方法,雖然在此之前它還不能處理雙向資料繫結,但是現在可以了。

您的技能如何?您最擅長哪種電腦語言?如果您編寫過許多 Visual Basic 6.0 代碼,並且像很多人一樣使用 Visual Basic .NET 有一段時間了,那麼“按邏輯”移植代碼對您來說可能更容易。這就是變換操作,而不是代碼本身。只要不使用伺服器端遊標,您就能夠利用大多數連接字串和 SQL。如果您的技能目前還沒有達到這個水平,那麼嘗試從使用 Visual Studio 2005 遷移嚮導開始可能會更容易,這是因為大多數簡單情況下進行的轉換都不難。

您的代碼在多大程度上依賴於伺服器端功能,例如,鍵集、動態資料指標或管理伺服器端狀態的常式(如 #temp 表)?在這種情況下,轉換過程將更困難,因為即使是最新的 ADO.NET 2.0 也不直接支援該功能。但是,有一個替代辦法 — 使用 ANSI CURSOR 命令。(請參閱我的文章使用 ANSI CURSOR 語句)。

您是從 ADO 經典(ADOc 1.0 至 2.6 版)、DAO、ODBC 還是其他某個專用資料提供者進行遷移?從比較新的 ADO 版本進行遷移要容易得多,因為很多概念是相似的 — 不是相同,而是相似。如果使用 Visual Basic 6.0 遷移嚮導,則無需改動即可移植大部分 ADOc 代碼。當然,這會出現一些問題,我在以前的文章中提到過。

但是,從 DAO、ODBC API 或專用介面進行遷移卻是另一回事。自動化嚮導可能根本不能轉換您的代碼,甚至連嘗試一下都不行。如果是這樣,我建議您重新分析 DBMS 引擎。如果先使用 DAO,然後又使用 JET,我通常建議客戶從 JET 遷移到 SQL Express,因為它更強大、更穩定並且具有更高的可擴充性。Microsoft 正在儘可能快速地全面替換 JET,我建議客戶和學生也儘快替換。

您使用的繫結控制項是什嗎?儘管某些簡單控制項(如 TextBox、ListBox 和 ComboBox)的轉換路徑相當簡單,但 DataGrid 卻不是。Visual Basic .NET 中的綁定機制從根本上進行了改進並具有重大差異,因此在遷移複雜的繫結控制項時,您可能會發現一些不連貫的地方。許多屬性在 .NET 等效控制項中不一樣了,而且一些方法也沒有了。第三方控制項通常以 .NET 版本提供 — 您可能希望在冒險使用這些控制項之前先調查一下。至於自訂控制項,Visual Studio 2005 轉換這些控制項的效果更好,但是您不要期望過高 — 我懷疑這個轉換嚮導的新增功能會出現很多問題。

您準備編寫自己的 SQL 操作命令邏輯嗎?別忘了,ADO 經典在運行時會根據 SELECT 語句為您建立該 SQL。相反,ADO.NET 則鼓勵您自己編寫這些操作命令的代碼。如前所述,您可以使用 CommandBuilder 並很快捨棄其局限性。我認為您將發現它不像 ADO 經典的 Update 方法那樣靈活 — 特別是考慮到 Update Criteria 屬性允許您更改所建立的操作命令的類型時更是如此。

 

小結

是的,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)



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。