資料通路：使用 ADO.NET 的最佳實踐

釋出日期： 4/1/2004 | 更新日期： 4/1/2004

摘要：

編寫 Microsoft ADO.NET 代碼的最佳實踐，以及對使用 ADO.NET 中可用對象的開發人員的建議。（21 頁列印頁）

注

如果對 ADO.NET 和 .NET 架構不熟悉，請參閱 .NET 架構 SDK 中的 Accessing Data with ADO.NET 部分。如果您是 ADO 程式員，并對将應用程式遷移到 ADO.NET 感興趣，請參閱 ADO.NET for the ADO Programmer，以獲得更多資訊。

使用 ADO.NET 的最佳實踐

Dennis Lu

Doug Rothaus

Microsoft Corporation

2002 年 7 月

适用于：

具有使用 Microsoft ADO.NET 和 Microsoft® .NET 架構開發經驗的人員

本頁内容

	簡介
	.NET 架構資料提供程式
	使用 DataReader、DataSet、DataAdapter 和 DataView
	使用指令
	使用連接配接
	與 XML 內建
	更多有用的技巧

簡介

本文為您提供了在 Microsoft ADO.NET 應用程式中實作和獲得最佳性能、可伸縮性以及功能的最佳解決方案；同時也講述了使用 ADO.NET 中可用對象的最佳實踐；并提出一些有助于優化 ADO.NET 應用程式設計的建議。

本文包含：

•	有關 .NET 架構包含的 .NET 架構資料提供程式的資訊。
•	DataSet 和 DataReader 之間的比較，以及這些對象中每個對象最佳用法的解釋。
•	解釋如何使用 DataSet 、 Commands 和 Connections 。
•	有關與 XML 內建的資訊。
•	通用的技巧和問題。

關于 ADO.NET 最佳實踐的附加資訊，請參閱 MSDN Library 中的 .NET Data Access Architecture Guide 部分。注意，“.NET Data Access Architecture Guide”主要側重于使用 Microsoft SQL Server 7.0 或更高版本的結構。

下面的清單提供了有關 ADO.NET 的附加資訊：

•	新聞討論區：通過位于 news://msnews.microsoft.com/microsoft.public.dotnet.framework.adonet 的 NNTP 新聞閱讀程式或通過位于 http://msdn.microsoft.com/newsgroups/loadframes.asp 的 Web 浏覽器，可以通路 BDA 新聞討論區。
•	讨論清單： http://www.asplists.com/asplists/aspngdata.asp http://discuss.develop.com/dotnet.html

傳回頁首

.NET 架構資料提供程式

.NET 架構中的資料提供程式在應用程式和資料源之間起到橋梁作用。.NET 架構資料提供程式能夠從資料源中傳回查詢結果、對資料源執行指令、将

DataSet

中的更改傳播給資料源。本文包括有關哪個 .NET 架構資料提供程式是最适合您需要的一些技巧。

使用哪個 .NET 架構資料提供程式？

為了使您的應用程式獲得最佳性能，請使用最适合您的資料源的 .NET 架構資料提供程式。有許多資料提供程式可供您的應用程式選用。下表提供了關于可用資料提供程式的資訊，以及每個資料提供程式最适合哪個資料源。

提供程式	詳細資訊
SQL Server .NET 資料提供程式	可在 System.Data.SqlClient 命名空間中找到。 建議那些使用 Microsoft SQL Server 7.0 版或更高版本的中間層應用程式使用。 建議那些使用 Microsoft Data Engine (MSDE) 或 Microsoft SQL Server 7.0 版或更高版本的單層應用程式使用。 對于 Microsoft SQL Server 6.5 版和更早版本，必須将用于 SQL Server 的 OLE DB 提供程式與 OLE DB .NET 資料提供程式一起使用。
OLE DB .NET 資料提供程式	可在 System.Data.OleDb 命名空間中找到。 建議那些使用 Microsoft SQL Server 6.5 版或更早版本，或支援 .NET 架構 SDK 的 OLE DB .NET 資料提供程式使用的 OLE DB 接口中列出的任何 OLE DB 接口的 OLE DB 提供程式的中間層應用程式使用。（OLE DB 2.5 接口不需要。） 對于 Microsoft SQL Server 7.0 或更高版本，建議使用 SQL Server 的 .NET 架構資料提供程式。 建議那些使用 Microsoft廬 Access 資料庫的單層應用程式使用。不建議中間層應用程式使用 Access 資料庫。 禁用 ODBC (MSDASQL) 的 OLE DB 提供程式支援。要通路開放式資料庫連接配接 (ODBC) 資料源，可以下載下傳 ODBC .NET 資料提供程式，并且 .NET 架構 SDK 1.1 版将包含它。
ODBC .NET 資料提供程式	可以下載下傳 ODBC .NET 資料提供程式。 可在 Microsoft.Data.Odbc 命名空間中找到。 提供對通過 ODBC 驅動程式連接配接的資料源的通路。 注 ODBC 資料提供程式将包含在即将釋出的以 1.1 為起始的 .NET 架構版本中。包含的 ODBC .NET 資料提供程式的命名空間是 System.Data.Odbc 。
用于 Oracle 的 .NET 資料提供程式	可以下載下傳用于 Oracle 的 Microsoft .NET 資料提供程式。 可在 System.Data.OracleClient 命名空間中找到。 提供對 Oracle 資料源（版本 8.1.7 及更高版本）的通路。 注 用于 Oracle 的 .NET 資料提供程式将包含在即将釋出的以 1.1 為起始的 .NET 架構版本中。
自定義 .NET 資料提供程式	ADO.NET 提供了最小的一組接口，使您能實作自己的 .NET 架構資料提供程式。有關建立自定義資料提供程式的更多資訊，請參閱 .NET 架構 SDK 中的 Implementing a .NET Data Provider。
SQLXML 托管類	用于 Microsoft SQL Server 2000 的 XML 釋出 (SQLXML 3.0) 包含 SQLXML 托管類，它能從 .NET 架構通路 Microsoft SQL Server 2000 及其更高版本的 XML 功能。例如，這些類使您可以執行 XML 模闆、對伺服器上的資料執行 XML 路徑語言 (XPath) 查詢、或者用 Updategrams 或 Diffgrams 執行資料更新。 SQLXML 3.0 以 SQLXML 1.0 及 2.0 的功能為基礎，為 SQL Server 2000 引入了 Web 服務。對于 SQLXML 3.0，存儲過程和 XML 模闆能通過 SOAP 公開為 Web 服務。 可以下載下傳 SQLXML 3.0。

連接配接到 SQL Server 7.0 或更高版本

為了在連接配接到 Microsoft SQL Server 7.0 或更高版本時獲得最佳性能，請使用 SQL Server .NET 資料提供程式。SQL Server .NET 資料提供程式的設計目的就在于不通過任何附加技術層就可以直接通路 SQL Server。圖 1 說明了可用于通路 SQL Server 7.0 或更高版本的不同技術之間的差別。

圖 1. 通路 SQL Server 7.0 或更高版本的連接配接方法 連接配接到 ODBC 資料源

ODBC .NET 資料提供程式可在

Microsoft.Data.Odbc

命名空間中找到，它的結構與用于SQL Server 和 OLE DB 的 .NET 資料提供程式相同。ODBC .NET 資料提供程式（可下載下傳）遵循命名約定 — 以 "ODBC" 為字首（例如，

OdbcConnection

），并使用标準 ODBC 連接配接字元串。

注

ODBC .NET 資料提供程式将包含在以 1.1 為起始的 .NET 架構版本中。包含的 ODBC .NET 資料提供程式的命名空間是

System.Data.Odbc

。

傳回頁首

使用 DataReader、DataSet、DataAdapter 和 DataView

ADO.NET 提供以下兩個對象，用于檢索關系資料并将其存儲在記憶體中：

DataSet

和

DataReader

。

DataSet

提供一個記憶體中資料的關系表示形式，一整套包括一些表在内的資料（這些表包含資料、對資料進行排序并限制資料），以及表之間的關系。

DataReader

提供一個來自資料庫的快速、隻進、隻讀資料流。

當使用

DataSet

時，經常會利用

DataAdapter

（也可能是

CommandBuilder

）與資料源進行互動。當使用

DataSet

時，也可以利用

DataView

對

DataSet

中的資料應用排序和篩選。也可以從

DataSet

繼承，建立強類型

DataSet

，用于将表、行和列作為強類型對象屬性公開。

下列主題包括的資訊涉及：使用

DataSet

或

DataReader

的最佳時機、如何優化通路它們所包含資料、以及如何優化使用

DataAdapter

（包括

CommandBuilder

）和

DataView

的技巧。

DataSet 與 DataReader

當設計應用程式時，要考慮應用程式所需功能的等級，以确定使用

DataSet

或者是

DataReader

。

要通過應用程式執行以下操作，就要使用

DataSet

：

•	在結果的多個離散表之間進行導航。
•	操作來自多個資料源（例如，來自多個資料庫、一個 XML 檔案和一個電子表格的混合資料）的資料。
•	在各層之間交換資料或使用 XML Web 服務。與 DataReader 不同的是， DataSet 能傳遞給遠端用戶端。
•	重用同樣的行組，以便通過緩存獲得性能改善（例如排序、搜尋或篩選資料）。
•	每行執行大量處理。對使用 DataReader 傳回的每一行進行擴充處理會延長服務于 DataReader 的連接配接的必要時間，這影響了性能。
•	使用 XML 操作對資料進行操作，例如可擴充樣式表語言轉換（XSLT 轉換）或 XPath 查詢。

對于下列情況，要在應用程式中使用

DataReader

：

•	不需要緩存資料。
•	要處理的結果集太大，記憶體中放不下。
•	一旦需要以隻進、隻讀方式快速通路資料。

注

填充

DataSet

時，

DataAdapter

使用

DataReader

。是以，使用

DataAdapter

取代

DataSet

提升的性能表現為節省了

DataSet

占用記憶體和填充

DataSet

需要的循環。一般來說，此性能提升隻是象征性的，是以，設計決策應以所需功能為基礎。

使用強類型 DataSet 的好處 DataSet

的另一個好處是可被繼承以建立一個強類型

DataSet

。強類型

DataSet

的好處包括設計時類型檢查，以及 Microsoft廬 Visual Studio廬 .NET 用于強類型

DataSet

語句結束所帶來的好處。修改了

DataSet

的架構或關系結構後，就可以建立一個強類型

DataSet

，把行和列作為對象的屬性公開，而不是作為集合中的項公開。例如，不公開客戶表中行的姓名列，而公開

Customer

對象的

Name

屬性。類型化

DataSet

從

DataSet

類派生，是以不會犧牲

DataSet

的任何功能。也就是說，類型化

DataSet

仍能遠端通路，并作為資料綁定控件（例如

DataGrid

）的資料源提供。如果架構事先不可知，仍能受益于通用

DataSet

的功能，但卻不能受益于強類型

DataSet

的附加功能。

處理強類型 DataSet 中的空引用

使用強類型

DataSet

時，可以批注

DataSet

的 XML 架構定義語言 (XSD) 架構，以確定強類型

DataSet

正确處理空引用。

nullValue

批注使您可用一個指定的值

String.Empty

代替

DBNull

、保留白引用或引發異常。選擇哪個選項取決于應用程式的上下文。預設情況下，如果遇到空引用，就會引發異常。

有關更多資訊，請參閱 Working with a Typed DataSet。

重新整理 DataSet 中的資料

如果想用伺服器上的更新值重新整理

DataSet

中的值，就使用

DataAdapter.Fill

。如果有在

DataTable

上定義的主鍵，

DataAdapter.Fill

會根據主鍵進行新行比對，并且當更改到現有行時應用伺服器上的值。即使重新整理之前修改了它們，重新整理行的

RowState

仍被設定為

Unchanged

。注意，如果沒有為

DataTable

定義主鍵，

DataAdapter.Fill

就用可能重複的主鍵值添加新行。

如果想用來自伺服器的目前值重新整理表，并同時保留對表中的行所做的任何更改，必須首先用

DataAdapter.Fill

填充表，并填充一個新的

DataTable

，然後用

preserveChanges

值

true

把

DataTable Merge

到

DataSet

中。

在 DataSet 中搜尋資料

在

DataSet

中查詢與特定條件相比對的行時，可以利用基于索引的查找提高搜尋性能。當把

PrimaryKey

值賦給

DataTable

時，會建立一個索引。當給

DataTable

建立

DataView

時，也會建立一個索引。下面是一些利用基于索引進行查找的技巧。

•	如果對組成 DataTable 的 PrimaryKey 的列進行查詢，要使用 DataTable.Rows.Find 而不是 DataTable.Select 。
•	對于涉及到非主鍵列的查詢，可以使用 DataView 為資料的多個查詢提高性能。當把排序順序應用到 DataView 時，就會建立一個搜尋時使用的索引。 DataView 公開 Find 和 FindRows 方法，以便查詢基礎 DataTable 中的資料。
•	如果不需要表的排序視圖，仍可以通過為 DataTable 建立 DataView 來利用基于索引的查找。注意，隻有對資料執行多個查詢操作時，這樣才會帶來好處。如果隻執行單一查詢，建立索引所需要的處理就會降低使用索引所帶來的性能提升。

DataView 構造

如果建立了

DataView

，并且修改了

Sort

、

RowFilter

或

RowStateFilter

屬性，

DataView

就會為基礎

DataTable

中的資料建立索引。建立

DataView

對象時，要使用

DataView

構造函數，它用

Sort

、

RowFilter

和

RowStateFilter

值作為構造函數參數（與基礎

DataTable

一起）。結果是建立了一次索引。建立一個“空”

DataView

并随後設定

Sort

、

RowFilter

或

RowStateFilter

屬性，會導緻索引至少建立兩次。

分頁

ADO.NET 可以顯式控制從資料源中傳回什麼樣的資料，以及在

DataSet

中本地緩存多少資料。對查詢結果的分頁沒有唯一的答案，但下面有一些設計應用程式時應該考慮的技巧。

•	避免使用帶有 startRecord 和 maxRecords 值的 DataAdapter.Fill 重載。當以這種方式填充 DataSet 時，隻有 maxRecords 參數（從 startRecord 參數辨別的記錄開始）指定的記錄數量用于填充 DataSet ，但無論如何總是傳回完整的查詢。這就會引起不必要的處理，用于讀取“不需要的”記錄；而且為了傳回附加記錄，會耗盡不必要的伺服器資源。
•	用于每次隻傳回一頁記錄的技術是建立 SQL 語句，把 WHERE 子句以及 ORDER BY 子句和 TOP 謂詞組合起來。此技術取決于存在一種可唯一辨別每一行的辦法。當浏覽下一頁記錄時，修改 WHERE 子句使之包含所有唯一辨別符大于目前頁最後一個唯一辨別符的記錄。當浏覽上一頁記錄時，修改 WHERE 子句使之傳回所有唯一辨別符小于目前頁第一個唯一辨別符的記錄。兩種查詢都隻傳回記錄的 TOP 頁。當浏覽上一頁時，需要以降序為結果排序。這将有效地傳回查詢的最後一頁（如果需要，顯示之前也許要重新排序結果）。有關這個技術的一個示例，請參閱 Paging Through a Query Result。
•	另一項每次隻傳回一頁記錄的技術是建立 SQL 語句，把 TOP 謂詞和嵌入式 SELECT 語句的使用結合在一起。此技術并不依賴于存在一種可唯一辨別每一行的辦法。使用這項技術的第一步是把所需頁的數量與頁大小相乘。然後将結果傳遞給 SQL Query 的 TOP 謂詞，該查詢以升序排列。再把此查詢嵌入到另一個查詢中，後者從降序排列的嵌入式查詢結果中選擇 TOP 頁大小。實質上，傳回的是嵌入式查詢的最後一頁。例如，要傳回查詢結果的第三頁（頁大小是 10），應該書寫如下所示的指令： SELECT TOP 10 * FROM (SELECT TOP 30 * FROM Customers ORDER BY Id ASC) AS Table1 ORDER BY Id DESC 注意，從查詢中傳回的結果頁以降序顯示。如果需要，應該重新排序。
•	如果資料不經常變動，可以在 DataSet 中本地維護一個記錄緩存，以此提高性能。例如，可以在本地 DataSet 中存儲 10 頁有用的資料，并且隻有當使用者浏覽超出緩存第一頁和最後一頁時，才從資料源中查詢新資料。

有關更多資訊，請參閱 .NET Data Access Architecture Guide。

用架構填充 DataSet

當用資料填充

DataSet

時，

DataAdapter.Fill

方法使用

DataSet

的現有架構，并使用從

SelectCommand

傳回的資料填充它。如果在

DataSet

中沒有表名與要被填充的表名相比對，

Fill

方法就會建立一個表。預設情況下，

Fill

僅定義列和列類型。

通過設定

DataAdapter

的

MissingSchemaAction

屬性，可以重寫

Fill

的預設行為。例如，要讓

Fill

建立一個表架構，并且還包括主鍵資訊、唯一限制、列屬性、是否允許為空、最大列長度、隻讀列和自動增量的列，就要把

DataAdapter.MissingSchemaAction

指定為

MissingSchemaAction.AddWithKey

。或者，在調用

DataAdapter.Fill

前，可以調用

DataAdapter.FillSchema

來確定當填充

DataSet

時架構已到位。

對

FillSchema

的調用會産生一個到伺服器的額外行程，用于檢索附加架構資訊。為了獲得最佳性能，需要在調用

Fill

之前指定

DataSet

的架構，或者設定

DataAdapter

的

MissingSchemaAction

。

使用 CommandBuilder 的最佳實踐

假設

SelectCommand

執行單一表 SELECT，

CommandBuilder

就會以

DataAdapter

的

SelectCommand

屬性為基礎自動生成

DataAdapter

的

InsertCommand

、

UpdateCommand

、和

DeleteCommand

屬性。下面是為獲得最佳性能而使用

CommandBuilder

的一些技巧。

•	CommandBuilder 的使用應該限制在設計時或即席方案中。生成 DataAdapter 指令屬性所必需的處理會影響性能。如果預先知道 INSERT/UPDATE/DELETE 語句的内容，就顯式設定它們。一個比較好的設計技巧是，為 INSERT/UPDATE/DELETE 指令建立存儲過程并顯式配置 DataAdapter 指令屬性以使用它們。
•	CommandBuilder 使用 DataAdapter 的 SelectCommand 屬性确定其他指令屬性的值。如果 DataAdapter 的 SelectCommand 本身曾經更改過，確定調用 RefreshSchema 以更新指令屬性。
•	如果 DataAdapter 指令屬性為空（指令屬性預設情況下為空）， CommandBuilder 僅僅為它生成一條指令。如果顯式設定了指令屬性， CommandBuilder 不會重寫它。如果希望 CommandBuilder 為以前已經設定過的指令屬性生成指令，就把指令屬性設定為空。

批處理 SQL 語句

很多資料庫支援把多條指令合并或批處理成一條單一指令執行。例如，SQL Server 使您可以用分号 (;) 分隔指令。把多條指令合并成單一指令，能減少到伺服器的行程數，并提高應用程式的性能。例如，可以把所有預定的删除在應用程式中本地存儲起來，然後再發出一條批處理指令調用，從資料源删除它們。

雖然這樣做确實能提高性能，但是，當對

DataSet

中的資料更新進行管理時，可能會增加應用程式的複雜性。要保持簡單，可能要在

DataSet

中為每個

DataTable

建立一個

DataAdapter

。

用多個表填充 DataSet

如果使用批處理 SQL 語句檢索多個表并填充

DataSet

，第一個表用指定給

Fill

方法的表名命名。後面的表用指定給

Fill

方法的表名加上一個從 1 開始并且增量為 1 的數字命名。例如，如果運作下面的代碼：

'Visual Basic
Dim da As SqlDataAdapter = New SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection)
Dim ds As DataSet = New DataSet()
da.Fill(ds, "Customers")

//C#
SqlDataAdapter da = new SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection);
DataSet ds = new DataSet();
da.Fill(ds, "Customers");      

來自 Customers 表的資料放在名為 "Customers" 的

DataTable

中。來自 Orders 表的資料放在名為 "Customers1" 的

DataTable

中。

填充完

DataSet

之後，可以很容易地把 "Customers1" 表的

TableName

屬性改為 "Orders"。但是，後面的填充會導緻 "Customers" 表被重新填充，而 "Orders" 表會被忽略，并建立另外一個 "Customers1" 表。為了對這種情況作出補救，建立一個

DataTableMapping

，把 "Customers1" 映射到 "Orders"，并為其他後面的表建立其他的表映射。例如：

'Visual Basic
Dim da As SqlDataAdapter = New SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection)
da.TableMappings.Add("Customers1", "Orders")
Dim ds As DataSet = New DataSet()
da.Fill(ds, "Customers")

//C#
SqlDataAdapter da = new SqlDataAdapter("SELECT * FROM Customers; SELECT * FROM Orders;", myConnection);
da.TableMappings.Add("Customers1", "Orders");
DataSet ds = new DataSet();
da.Fill(ds, "Customers");      

使用 DataReader

下面是一些使用

DataReader

獲得最佳性能的技巧，同時還回答了一些關于使用

DataReader

的常見問題。

•	在通路相關 Command 的任何輸出參數之前，必須關閉 DataReader 。
•	完成讀資料之後總是要關閉 DataReader 。如果使用 Connection 隻是用于傳回 DataReader ，那麼關閉 DataReader 之後立刻關閉它。 另外一個顯式關閉 Connection 的方法是把 CommandBehavior.CloseConnection 傳遞給 ExecuteReader 方法，以確定相關的連接配接在關閉 DataReader 時被關閉。如果從一個方法傳回 DataReader ，而且不能控制 DataReader 或相關連接配接的關閉，則這樣做特别有用。
•	不能在層之間遠端通路 DataReader 。 DataReader 是為已連接配接好的資料通路設計的。
•	當通路列資料時，使用類型化通路器，例如， GetString 、 GetInt32 等。這使您不用進行将 GetValue 傳回的 Object 強制轉換成特定類型所需的處理。
•	一個單一連接配接每次隻能打開一個 DataReader 。在 ADO 中，如果打開一個單一連接配接，并且請求兩個使用隻進、隻讀遊标的記錄集，那麼 ADO 會在遊标生存期内隐式打開第二個、未池化的到資料存儲區的連接配接，然後再隐式關閉該連接配接。對于 ADO.NET，“秘密”完成的動作很少。如果想在相同的資料存儲區上同時打開兩個 DataReaders ，就必須顯式建立兩個連接配接，每個 DataReader 一個。這是 ADO.NET 為池化連接配接的使用提供更多控制的一種方法。
•	預設情況下， DataReader 每次 Read 時都要把整行加載到記憶體。這允許在目前行内随機通路列。如果不需要這種随機通路，為了提高性能，就把 CommandBehavior.SequentialAccess 傳遞給 ExecuteReader 調用。這将 DataReader 的預設行為更改為僅在請求時将資料加載到記憶體。注意， CommandBehavior.SequentialAccess 要求順序通路傳回的列。也就是說，一旦讀過傳回的列，就不能再讀它的值了。
•	如果已經完成讀取來自 DataReader 的資料，但仍然有大量挂起的未讀結果，就在調用 DataReader 的 Close 之前先調用 Command 的 Cancel 。調用 DataReader 的 Close 會導緻在關閉遊标之前檢索挂起的結果并清空流。調用 Command 的 Cancel 會放棄伺服器上的結果，這樣， DataReader 在關閉的時候就不必讀這些結果。如果要從 Command 傳回輸出參數，還要調用 Cancel 放棄它們。如果需要讀取任何輸出參數，不要調用 Command 的 Cancel ，隻要調用 DataReader 的 Close 即可。

二進制大對象 (BLOB)

用

DataReader

檢索二進制大對象 (BLOB) 時，應該把

CommandBehavior.SequentialAccess

傳遞給

ExecuteReader

方法調用。因為

DataReader

的預設行為是每次

Read

都把整行加載到記憶體，又因為 BLOB 值可能非常大，是以結果可能由于單個 BLOB 而使大量記憶體被用光。

SequentialAccess

将

DataReader

的行為設定為隻加載請求的資料。然後還可以使用

GetBytes

或

GetChars

控制每次加載多少資料。

記住，使用

SequentialAccess

時，不能不按順序通路

DataReader

傳回的不同字段。也就是說，如果查詢傳回三列，其中第三列是 BLOB，并且想通路前兩列中的資料，就必須在通路 BLOB 資料之前先通路第一列的值，然後通路第二列的值。這是因為現在資料是順序傳回的，并且

DataReader

一旦讀過該資料，該資料就不再可用。

有關如何在 ADO.NET 中通路 BLOB 的較長的描述，請參閱 Obtaining BLOB Values from a Database。

傳回頁首

使用指令

ADO.NET 提供了幾種指令執行的不同方法以及優化指令執行的不同選項。下面包括一些技巧，它們是關于選擇最佳指令執行以及如何提高執行指令的性能。

使用 OleDbCommand 的最佳實踐

不同 .NET 架構資料提供程式之間的指令執行被盡可能标準化了。但是，資料提供程式之間仍然存在差異。下面給出一些技巧，可微調用于 OLE DB 的 .NET 架構資料提供程式的指令執行。

•	按照 ODBC CALL 文法使用 CommandType.Text 調用存儲過程。使用 CommandType.StoredProcedure 隻是秘密地生成 ODBC CALL 文法。
•	一定要設定 OleDbParameter 的類型、大小（如果适用）、以及精度和範圍（如果參數類型是 numeric 或 decimal）。注意，如果不顯式提供參數資訊， OleDbCommand 會為每個執行指令重新建立 OLE DB 參數通路器。

使用 SqlCommand 的最佳實踐

使用

SqlCommand

執行存儲過程的快速提示：如果調用存儲過程，将

SqlCommand

的

CommandType

屬性指定為

StoredProcedure

的

CommandType

。這樣通過将該指令顯式辨別為存儲過程，就不需要在執行之前分析指令。

使用 Prepare 方法

對于重複作用于資料源的參數化指令，

Command.Prepare

方法能提高性能。

Prepare

訓示資料源為多次調用優化指定的指令。要想有效利用

Prepare

，需要徹底了解資料源是如何響應

Prepare

調用的。對于一些資料源（例如 SQL Server 2000），指令是隐式優化的，不必調用

Prepare

。對于其他（例如 SQL Server 7.0）資料源，

Prepare

會比較有效。

顯式指定架構和中繼資料

隻要使用者沒有指定中繼資料資訊，ADO.NET 的許多對象就會推斷中繼資料資訊。下面是一些示例：

•	DataAdapter.Fill 方法，如果 DataSet 中沒有表和列， DataAdapter.Fill 方法會在 DataSet 中建立表和列。
•	CommandBuilder ，它會為單表 SELECT 指令生成 DataAdapter 指令屬性。
•	CommandBuilder.DeriveParameters ，它會填充 Command 對象的 Parameters 集合。

但是，每次用到這些特性，都會有性能損失。建議将這些特性主要用于設計時和即席應用程式中。在可能的情況下，顯式指定架構和中繼資料。其中包括在

DataSet

中定義表和列、定義

DataAdapter

的

Command

屬性、以及為

Command

定義

Parameter

資訊。

ExecuteScalar 和 ExecuteNonQuery

如果想傳回像 Count(*)、Sum(Price) 或 Avg(Quantity) 的結果那樣的單值，可以使用

Command.ExecuteScalar

。

ExecuteScalar

傳回第一行第一列的值，将結果集作為标量值傳回。因為單獨一步就能完成，是以

ExecuteScalar

不僅簡化了代碼，還提高了性能；要是使用

DataReader

就需要兩步才能完成（即，

ExecuteReader

+ 取值）。

使用不傳回行的 SQL 語句時，例如修改資料（例如INSERT、UPDATE 或 DELETE）或僅傳回輸出參數或傳回值，請使用

ExecuteNonQuery

。這避免了用于建立空

DataReader

的任何不必要處理。

有關更多資訊，請參閱 Executing a Command。

測試 Null

如果表（在資料庫中）中的列允許為空，就不能測試參數值是否“等于”空。相反，需要寫一個 WHERE 子句，測試列和參數是否都為空。下面的 SQL 語句傳回一些行，它們的 LastName 列等于賦給 @LastName 參數的值，或者 LastName 列和 @LastName 參數都為空。

SELECT * FROM Customers
WHERE ((LastName = @LastName) OR (LastName IS NULL AND @LastName IS NULL))      

把 Null 作為參數值傳遞

對資料庫的指令中，當把空值作為參數值發送時，不能使用

null

（Visual Basic廬 .NET 中為

Nothing

）。而需要使用

DBNull.Value

。例如：

'Visual Basic
Dim param As SqlParameter = New SqlParameter("@Name", SqlDbType.NVarChar, 20)
param.Value = DBNull.Value

//C#
SqlParameter param = new SqlParameter("@Name", SqlDbType.NVarChar, 20);
param.Value = DBNull.Value;      

執行事務

ADO.NET 的事務模型已經更改。在 ADO 中，當調用

StartTransaction

時，調用之後的任何更新操作都被視為是事務的一部分。但是，在 ADO.NET 中，當調用

Connection.BeginTransaction

時，會傳回一個

Transaction

對象，需要把它與

Command

的

Transaction

屬性聯系起來。這種設計可以在一個單一連接配接上執行多個根事務。如果未将

Command.Transaction

屬性設定為一個針對相關的

Connection

而啟動的

Transaction

，那麼

Command

就會失敗并引發異常。

即将釋出的 .NET 架構将使您可以在現有的分布式事務中手動登記。這對于對象池方案來說很理想；在該方案中，一個池對象打開一次連接配接，但是在多個獨立的事務中都涉及到該對象。.NET 架構 1.0 發行版中這一功能并不可用。

有關事務的更多資訊，請參閱 Performing Transactions 以及 .NET Data Access Architecture Guide。

傳回頁首

使用連接配接

高性能應用程式與使用中的資料源保持最短時間的連接配接，并且利用性能增強技術，例如連接配接池。下面的主題提供一些技巧，有助于在使用 ADO.NET 連接配接到資料源時獲得更好的性能。

連接配接池

用于 ODBC 的 SQL Server、OLE DB 和 .NET 架構資料提供程式隐式緩沖連接配接。通過在連接配接字元串中指定不同的屬性值，可以控制連接配接池的行為。有關如何控制連接配接池的行為的詳細資訊，請參閱 Connection Pooling for the SQL Server .NET Data Provider 和 Connection Pooling for the OLE DB .NET Data Provider。

用 DataAdapter 優化連接配接 DataAdapter

的

Fill

和

Update

方法在連接配接關閉的情況下自動打開為相關指令屬性指定的連接配接。如果

Fill

或

Update

方法打開了連接配接，

Fill

或

Update

将在操作完成的時候關閉它。為了獲得最佳性能，僅在需要時将與資料庫的連接配接保持為打開。同時，減少打開和關閉多操作連接配接的次數。

如果隻執行單個的

Fill

或

Update

方法調用，建議允許

Fill

或

Update

方法隐式打開和關閉連接配接。如果對

Fill

和/或

Update

調用有很多，建議顯式打開連接配接，調用

Fill

和/或

Update

，然後顯式關閉連接配接。

另外，當執行事務時，顯式地在開始事務之前打開連接配接，并在送出之後關閉連接配接。例如：

'Visual Basic
Public Sub RunSqlTransaction(da As SqlDataAdapter, myConnection As SqlConnection, ds As DataSet)
  myConnection.Open()
  Dim myTrans As SqlTransaction = myConnection.BeginTransaction()
  myCommand.Transaction = myTrans

  Try
    da.Update(ds)
    myTrans.Commit()
    Console.WriteLine("Update successful.")
  Catch e As Exception
    Try
      myTrans.Rollback()
    Catch ex As SqlException
      If Not myTrans.Connection Is Nothing Then
        Console.WriteLine("An exception of type " & ex.GetType().ToString() & _
                          " was encountered while attempting to roll back the transaction.")
      End If
    End Try

    Console.WriteLine("An exception of type " & e.GetType().ToString() & " was encountered.")
    Console.WriteLine("Update failed.")
  End Try
  myConnection.Close()
End Sub

//C#
public void RunSqlTransaction(SqlDataAdapter da, SqlConnection myConnection, DataSet ds)
{
  myConnection.Open();
  SqlTransaction myTrans = myConnection.BeginTransaction();
  myCommand.Transaction = myTrans;

  try
  {
    da.Update(ds);
    myCommand.Transaction.Commit();
    Console.WriteLine("Update successful.");
  }
  catch(Exception e)
  {
    try
    {
      myTrans.Rollback();
    }
    catch (SqlException ex)
    {
      if (myTrans.Connection != null)
      {
        Console.WriteLine("An exception of type " + ex.GetType() +
                          " was encountered while attempting to roll back the transaction.");
      }
    }

    Console.WriteLine(e.ToString());
    Console.WriteLine("Update failed.");
  }
  myConnection.Close();
}      

始終關閉 Connection 和 DataReader

完成對

Connection

或

DataReader

對象的使用後，總是顯式地關閉它們。盡管垃圾回收最終會清除對象并是以釋放連接配接和其他托管資源，但垃圾回收僅在需要時執行。是以，確定任何寶貴的資源被顯式釋放仍然是您的責任。并且，沒有顯式關閉的

Connections

可能不會傳回到池中。例如，一個超出作用範圍卻沒有顯式關閉的連接配接，隻有當池大小達到最大并且連接配接仍然有效時，才會被傳回到連接配接池中。

注

不要在類的

Finalize

方法中對

Connection

、

DataReader

或任何其他托管對象調用

Close

或

Dispose

。最後完成的時候，僅釋放類自己直接擁有的非托管資源。如果類沒有任何非托管資源，就不要在類定義中包含

Finalize

方法。

在 C# 中使用 "Using" 語句

對于 C# 程式員來說，確定始終關閉

Connection

和

DataReader

對象的一個友善的方法就是使用

using

語句。

using

語句在離開自己的作用範圍時，會自動調用被“使用”的對象的

Dispose

。例如：

//C#
string connString = "Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;";

using (SqlConnection conn = new SqlConnection(connString))
{
  SqlCommand cmd = conn.CreateCommand();
  cmd.CommandText = "SELECT CustomerId, CompanyName FROM Customers";
  
  conn.Open();

  using (SqlDataReader dr = cmd.ExecuteReader())
  {
    while (dr.Read())
      Console.WriteLine("{0}/t{1}", dr.GetString(0), dr.GetString(1));
  }
}      

Using 語句不能用于 Microsoft廬 Visual Basic廬 .NET。

避免通路 OleDbConnection.State 屬性

如果連接配接已經打開，

OleDbConnection.State

屬性會對

DBPROP_CONNECTIONSTATUS

屬性的

DATASOURCEINFO

屬性集執行本地 OLE DB 調用

IDBProperties.GetProperties

，這可能會導緻對資料源的往返行程。也就是說，檢查

State

屬性的代價可能很高。是以僅在需要時檢查

State

屬性。如果需要經常檢查該屬性，監聽

OleDbConnection

的

StateChange

事件可能會使應用程式的性能好一些。有關

StateChange

事件的詳細資訊，請參閱 Working with Connection Events。

傳回頁首

與 XML 內建

ADO.NET 在

DataSet

中提供了廣泛的 XML 內建，并公開了 SQL Server 2000 及其更高版本提供的部分 XML 功能。還可以使用 SQLXML 3.0 廣泛地通路 SQL Server 2000 及其更高版本中的 XML 功能。下面是使用 XML 和 ADO.NET 的技巧和資訊。

DataSet 和 XML DataSet

與 XML 緊密內建，并提供如下功能：

•	從 XSD 架構中加載 DataSet 的架構或關系型結構。
•	從 XML 加載 DataSet 的内容。
•	如果沒有提供架構，可以從 XML 文檔的内容推斷出 DataSet 的架構。
•	把 DataSet 的架構寫成 XSD 架構。
•	把 DataSet 的内容寫成 XML。
•	同步通路使用 DataSet 的資料的關系表示，以及使用 XmlDataDocument 的資料的層次表示。

注

可以使用這種同步把 XML 功能（例如，XPath 查詢和 XSLT 轉換）應用到

DataSet

中的資料，或者在保留原始 XML 保真度的前提下為 XML 文檔中資料的全部或其中一個子集提供關系視圖。

關于

DataSet

提供的 XML 功能的詳細資訊，請參閱 XML and the DataSet。

架構推斷

從 XML 檔案加載

DataSet

時，可以從 XSD 架構加載

DataSet

架構，或者在加載資料前預定義表和列。如果沒有可用的 XSD 架構，而且不知道為 XML 檔案的内容定義哪些表和列，就可以在 XML 文檔結構的基礎上對架構進行推斷。

架構推斷作為遷移工具很有用，但應隻限于設計階段應用程式，這是由于推斷處理有如下限制。

•	對架構的推斷會引入影響應用程式性能的附加處理。
•	所有推斷列的類型都是字元串。
•	推斷處理不具有确定性。也就是說，它是基于 XML 檔案内容的，而不是預定的架構。是以，對于兩個預定架構相同的 XML 檔案，由于它們的内容不同，結果得到兩個完全不同的推斷架構。

有關更多資訊，請參閱 Inferring DataSet Relational Structure from XML。

用于 XML 查詢的 SQL Server

如果正從 SQL Server 2000 FOR XML 傳回查詢結果，可以讓用于 SQL Server 的 .NET 架構資料提供程式使用

SqlCommand.ExecuteXmlReader

方法直接建立一個

XmlReader

。

SQLXML 托管類

.NET 架構中有一些類，公開用于 SQL Server 2000 的 XML 的功能。這些類可在

Microsoft.Data.SqlXml

命名空間中找到，它們添加了執行 XPath 查詢和 XML 模闆檔案以及把 XSLT 轉換應用到資料的能力。

SQLXML 托管類包含在用于 Microsoft SQL Server 2000 的 XML (SQLXML 2.0) 發行版中，可從 XML for Microsoft SQL Server 2000 Web Release 2 (SQLXML 2.0) ??μ?。

傳回頁首

更多有用的技巧

下面是一些編寫 ADO.NET 代碼時的通用技巧。

避免自動增量值沖突

就像大多數資料源一樣，

DataSet

使您可辨別那些添加新行時自動對其值進行遞增的列。在

DataSet

中使用自動增量的列時，如果自動增量的列來自資料源，可避免添加到

DataSet

的行和添加到資料源的行之間本地編号沖突。

例如，考慮一個表，它的主鍵列 CustomerID 是自動增量的。兩個新的客戶資訊行添加到表中，并接收到自動增量的 CustomerID 值 1 和 2。然後，隻有第二個客戶行被傳遞給

DataAdapter

的方法

Update

，新添加的行在資料源接收到一個自動增量的 CustomerID 值 1，與

DataSet

中的值 2 不比對。當

DataAdapter

用傳回值填充表中第二行時，就會出現限制沖突，因為第一個客戶行已經使用了 CustomerID 值 1。

要避免這種情況，建議在使用資料源上自動增量的列以及

DataSet

上自動增量的列時，把

DataSet

中的列建立為

AutoIncrementStep

值等于 -1 并且

AutoIncrementSeed

值等于 0，另外，還要確定資料源生成的自動增量辨別值從 1 開始，并且以正階值遞增。是以，

DataSet

為自動增量值生成負數，與資料源生成的正自動增量值不沖突。另外一個選擇是使用

Guid

類型的列，而不是自動增量的列。生成

Guid

值的算法應該永遠不會使資料源中生成的

Guid

值與

DataSet

中生成的

Guid

值一樣。

如果自動增量的列隻是用作唯一值，而且沒有任何意義，就考慮使用 Guid 代替自動增量的列。它們是唯一的，并且避免了使用自動增量的列所必需的額外工作。

有關從資料源檢索自動增量的列值的示例，請參閱 Retrieving Identity or AutoNumber Values。

檢查開放式并發沖突

按照設計，由于

DataSet

是與資料源斷開的，是以，當多個用戶端在資料源上按照開放式并發模型更新資料時，需要確定應用程式避免沖突。

在測試開放式并發沖突時有幾項技術。一項技術涉及在表中包含時間戳列。另外一項技術是，驗證一行中所有列的原始值是否仍然與通過在 SQL 語句中使用 WHERE 子句進行測試時在資料庫中找到的值相比對。

有關包含代碼示例的該主題的詳細讨論，請參閱 Optimistic Concurrency。

多線程程式設計

ADO.NET 對性能、吞吐量和可伸縮性進行優化。是以，ADO.NET 對象不鎖定資源，并且必須隻用于單線程。一個例外是

DataSet

，它對多個閱讀器是線程安全的。但是，在寫的時候需要把

DataSet

鎖定。

僅在需要的時候才用 COM Interop 通路 ADO

ADO.NET 的設計目的是成為許多應用程式的最佳解決方案。但是，有些應用程式需要隻有使用 ADO 對象才有的功能，例如，ADO 多元 (ADOMD)。在這些情況下，應用程式可以用 COM Interop 通路 ADO。注意使用 COM Interop 通路具有 ADO 的資料會導緻性能降低。在設計應用程式時，首先在實作用 COM Interop 通路 ADO 的設計之前，先确定 ADO.NET 是否滿足設計需求。

本文檔中包含的資訊代表了 Microsoft Corporation 在釋出之日對所讨論問題的目前觀點。由于 Microsoft 必須對不斷變化的市場情況做出響應，本文檔不應當被看作是 Microsoft 一方的承諾，Microsoft 也不保證在本文發表日期後所提供的任何資訊的準确性。

本白皮書隻用于資料用途。Microsoft 對本文檔提供的資訊不做任何明示的、暗示的或法令的保證。

遵守所有可适用版權法是使用者的責任。在不對版權法所規定的權利加以限制的情況下，未經 Microsoft Corporation 的書面明确許可，不得将本文檔的任何部分複制、存儲或引入到檢索系統，或以任何形式或手段（電子、機械、影印、錄制或其他）、或出于任何目的，傳播本文的任何部分。

Microsoft 對本文檔叙述的相關主題擁有專利權、專利申請權、商标權、版權或其他知識産權。除非 Microsoft 以任何書面許可協定明确提供，向您提供本文檔并沒給予您使用這些專利、商标、版權或其他知識産權的任何許可證。

漏 2002 Microsoft Corporation.保留所有權利。

Microsoft、Visual Basic、Visual Studio 是 Microsoft Corporation 在美國和/或其他國家/地區的注冊商标或商标。

本文所提到的真實公司和産品的名稱可能是屬于各自所有者的商标。

轉入原英文頁面