為 ADO 程式員設計的 ADO.NET (1)

來源:互聯網
上載者:User
ado|程式|程式員|設計 為 ADO 程式員設計的 ADO.NET

摘要:本文討論如何以 ADO.NET 方式實現基本資料庫操作,以及何時使用 ADO.NET 代替 ADO。

目錄


.NET 中的資料訪問
讀取資料
DataSet、DataTable 和 Recordset
轉換現有代碼
更新資料
XML 擴充支援
總結
自若干年前推出開放式資料庫連接 (ODBC) API (API) 以來,出現了各種各樣的資料庫訪問技術,而 ADO.NET 是其中最新的一種。在這過程中,發生了許多有趣的事。例如,COM 闖入資料庫領域,開始培植 OLE DB 的殖民進程。然後,大致相當於 OLE DB 自動化版本的 ActiveX® Data Objects (ADO) 被選來統治 Windows® 資料庫開發人員的 Visual Basic® 和 ASP 社區。
通過 .NET,Microsoft 正在提供通用架構(即 Framework Class Library),其中將包括所有現有的 Windows API 甚至更多的內容。特別值得一提的是,它包括大量常用的庫,而這些庫現在需要通過各個 COM 物件分別獲得。在這些庫中,您會發現 XML 和 ADO 物件模型,它們被整合到了叫做 ADO.NET 的類子樹中。
ADO.NET 事實上成為構建資料感知 .NET 應用程式的基礎。和 ADO 不同的是,ADO.NET 遵循更通用的原則,不那麼專門面向資料庫。ADO.NET 集合了所有允許資料處理的類。這些類表示具有典型資料庫功能(如索引、排序和視圖)的資料容器物件。儘管 ADO.NET 是 .NET 資料庫應用程式的權威解決方案,但從總體設計上來看,它不象 ADO 模型那樣以資料庫為中心,這是 ADO.NET 的一大特點。
ADO.NET 與 ADO 有很大差異。ADO.NET 是新的資料訪問編程模型,需要開發人員的全面理解、投入和新思維。然而,一旦開始掌握 ADO.NET,您將意識到:原有的 ADO 技巧非常有助於您以不同、卻更巧妙和可靠的方式來建立有效應用程式和解決各種老問題。
在這篇文章的其餘部分,我將集中介紹如何以 ADO.NET 方式實現基本的資料庫操作。我想說明,在什麼時候 ADO.NET 是比 ADO 更好的選擇,而您最好在什麼時候應放棄 ADO。ADO.NET 並不是將 ADO 改良以符合 .NET 基礎結構而形成的。只要您看一下 ADO.NET 的文法、代碼設計和移植,就會明白這一點。 .NET 中的資料訪問
在 ADO.NET 中訪問資料來源的方式由Managed 提供者確定。從功能上講,Managed 提供者與 OLE DB 的提供者非常相似,但有兩個重要的不同之處。首先,管理提供者在 .NET 環境中工作,通過 DataReader 和 DataTable 等 .NET 類檢索和公開資料。其次,因為它們的體繫結構針對 .NET 進行了最佳化,所以比較簡單。
目前 ADO.NET 提供了兩種Managed 提供者:一種用於 SQL Server™ 7.0 或更高版本,另一種用於其他所有您可能已經安裝的 OLE DB 提供者。在這兩種情況下您分別使用不同的類,但遵循相似的命名規則。除首碼外,名稱都是相同的。前一種情況首碼為 SQL,後一種情況則是 ADO。
您應該使用 SQL 類訪問 SQL Server 表,因為它們直接進入資料庫伺服器的內部 API,跳過了由 OLE DB 提供者表示的中介層。ADO 類是 OLE DB 提供者上的 .NET 介面,它們使用 COM Interop 橋進行工作。
ADO.NET 對象的初學者可參閱 Omri Gazitt 的文章介紹 ADO+:用於 Microsoft .NET 架構的資料訪問服務(英文)和我的 ADO+ 推動資料種類的演變(英文)一文。前者技術性較強,針對 ADO.NET 程式模型提供了高水平的評註性概述。後者主要介紹 ADO.NET 的目標和它與 XML、指令碼以及其他技術之間的聯絡。 讀取資料
需要從資料來源中讀取資料的 ADO.NET 應用程式首先要建立連線物件。根據目標提供者的不同,該連線物件可以是 SQLConnectionADOConnection。請記住,您可以使用 ADO.NET 類來串連到 SQL Server 資料庫,但我們不建議這樣做。其唯一的缺點是,您的代碼要通過不必要的額外代碼層。它先將 ADO 的Managed 提供者調入,然後Managed 提供者再調用 SQL Server OLE DB 提供者。而 SQL Server Managed 提供者和 OLE DB 提供者一樣直接操作資料。
ADO 和 ADO.NET 連線物件之間的顯著差異是:ADO.NET 串連不支援 CursorLocation 屬性。請注意,這並不是一個文檔錯誤,而是一個有爭議的設計問題。為了突出以資料為中心的原則,ADO.NET 沒有遊標的顯式實現。
在 ADO 中,您習慣了用遊標從資料庫或其他任何 OLE DB 相容的資料來源中抽取記錄。您可以選擇用戶端或伺服器資料指標,每種遊標都有幾個預先設定的遊標類型。ADO.NET 則設計為從資料來源中抽取資料,並提供新的編程介面來讀取和分析資料。
在 ADO 中,您通過指定串連和命令文本來建立 Recordset 對象。對於遊標的位置和類型,Recordset 有一定策略。您可以按下列方式之一讀取資料:
  • 在記憶體中建立選定記錄的靜態副本,然後在從資料來源中斷連線時根據需要處理這些記錄。ADO 稱之為靜態資料指標。

  • 通過快速、僅向前的唯讀遊標來滾動資料,這種遊標工作在記錄的靜態快照中。ADO 稱之為唯讀遊標。

  • 通過伺服器端的兩種遊標來訪問資料,這些遊標需要保持良好的串連,但您可以在各個不同層次上隨時檢測其他已串連的使用者的更改。ADO 稱它們為鍵集和動態資料指標。





前兩種方式都在中斷連線的記錄集內工作,並從用戶端緩衝讀取資訊,這是它們的相似之處。另外,在面向 Web 的環境中和對於新的 n 層系統,這兩種方式被證明是使用頻率最高的。
在 ADO 中,以上所有這些方式與不同類型的遊標相對應。您將在本文後面發現,雖然 ADO.NET 有很大不同,但它能實現您用 ADO 可實現的任何功能。只不過您的代碼將從實際資料來源及其實體儲存體媒介和格式中抽取資料。
ADO.NET 提供兩個對象來處理從資料來源中抽取的資料。它們是 DataSetDataReader 對象。前者是記錄在記憶體中的緩衝,您可以從任何方向隨意訪問和修改。後者是高度最佳化的對象,專為以僅向前方式滾動唯讀記錄而設計。請注意 DataSet 看起來象靜態資料指標,但實際上,在 .NET 中與 ADO 唯讀遊標相對應的是 DataReader 對象。
在 ADO.NET 中,不支援伺服器端遊標。然而,這不意味著您不能使用遊標。您需要做的是在 .NET 中匯入 ADO 類型庫。在項目視窗的 References 節點上單擊右鍵就行了。匯入之後,您便可以開始在應用程式中使用本地 ADO 對象了。
儘管我承認下決心轉向 .NET 是一件很難的事情,但我個人還是建議您考慮用 .NET 重寫現有應用程式。可以把完全匯入 ADO 作為邁向 .NET 的第一步,這無須投入太多的時間和資源。然而,請記住這隻是漫漫長路上的第一步。這絕不是您邁向 .NET 的唯一一步。.NET 具有超值價值的的真正原因在於統一和一致的編程介面以及對本地類的廣泛使用。您可以匯入 COM 類別型庫,但匯入 COM 類別型庫只能作為臨時解決方案或者中間步驟,我們並不鼓勵這樣做。
使用 ADO.NET 時,應當充分考慮到它統一了資料容器類編程介面這一事實。無論您打算編寫何種應用程式,Windows 表單、Web Form還是 Web 服務,都可以通過同一組類來處理資料。不管在後端的資料來源是 SQL Server 資料庫、OLE DB、XML 檔案還是一個數組,您都可以通過相同的方法和屬性來滾動和處理它們的內容。

adonetdev01.gif


圖 1:Solution Explorer 菜單
如果您堅持在 .NET 中使用 ADO,請準備面對一些副作用。例如,您需要額外的代碼才能夠從資料繫結控制項中使用記錄集。 DataSet、DataTable 和 Recordset
在 ADO.NET 中,沒有與 Recordset 對象直接對應的對象。最接近的是 DataTable 對象。儘管這兩個對象的功能幾乎一樣,但它們在各自的架構中起不同的作用。
Recordset 是一個大型物件,具有許多 ADO 功能,但還是有所欠缺。 Recordset 在很多方面效能優良,例如可建立性、中斷連線時仍能工作、功能豐富等等。但是,在某些方面仍然有待提高。例如,由於 Recordset 固有的 COM 特性,通過網路進行序列化的工作將非常繁重。又如它是二進位對象,所以在不同的平台上啟動並執行模組很難共用它,而且它不能穿過防火牆。另外, Recordset 表示多個記錄的單個表。如果該表是由一個或多個 JOIN 產生的,更新未經處理資料源可能會很困難。如果您要使中斷連線的記錄集和未經處理資料源保持協調,資料來源必須能夠識別 SQL。然而,您的記錄集很可能是通過非 SQL 提供者建立的。
在 ADO.NET 中,ADO Recordset 的所有功能被拆分成幾個較簡單的對象, DataReader 就是其中之一。 DataReader 類比快速、僅向前的唯讀遊標的操作。
DataTable 是一個表示資料來源的簡單對象。您可以手動構造 DataTable,也可以通過 DataSet 命令自動填滿它。 DataTable 不區分它所包含的資料的來源。該對象允許您在記憶體中處理資料,以及執行瀏覽、排序、編輯、應用篩選器、建立視圖等操作。
ADO 中沒有與 DataSet 相對應的對象。 DataSet 對象是一個容器類,是實現 ADO.NET 資料幫浦的關鍵對象。 DataSet 將一個或多個 DataTable 對象分組。 DataTable 通過象行和列這樣的通用集合公開它的內容。當您嘗試從資料表中讀取資料時,您可能會經過兩個不同的對象層: DataTableMappingDataView
DataTableMapping 對象描述了資料來源中的資料列和 DataTable 對象之間的映射關係。當填充 DataSet 時, DataSetCommand 對象要使用這個類。它維護資料集中的抽象列和資料來源中的物理列之間的連結。
表的視圖通過 DataView 對象實現。它表示 DataTable 的自訂視圖,可以綁定到特定控制項(如 Windows 表單和 Web Form中的資料格)中。該對象相當於 SQL CREATE VIEW 語句在記憶體中的實現。
DataSet 中的所有表都可以通過一個公用域放入關係中。這個關係由 DataRelation 對象管理。這看起來很象 ADO 的資料形成,但有一點重要區別。您不需要使用資料形成語言,您最終會擁有一個非常靈活的結構體系。ADO.NET 導航模型使您可以輕而易舉地從某一張表內的主行移入它的所有子行。
DataRelation 對象相當於 JOIN 語句在記憶體中的實現,可用於建立資料類型相同的列的父/子關係。一旦建立了關係,就不允許出現任何會破壞這種關係的更改,如果出現就會導致運行時異常。視圖和關係是實現主表/明細表架構的兩種方式。要記住,視圖只是放在記錄上的掩碼,而關係是設定在兩個表的一個或多個列之間的動態連結。如果使用關係,您不能更改順序或設定條件。
如果您的代碼需要一對一外鍵關係,並且不更改資料,那麼您最好不要使用無格式的 JOIN 命令。如果您需要額外的篩選功能,就應該使用 ADO.NET 自訂視圖。

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。