NET的數據訪問編程模式需要一套新的技巧和最佳方法。

ADO.NET提供了一個統一的編程模式和一組公用的類來進行任何類型的數據訪問，而不管你用何種語言來開發代碼。ADO.NET是全新的，但又與ADO儘可能保持一致，它使編程模式從一個客戶端/服務器、基於連接的模式轉變到了一個新的模式，這個新模式可以讓斷開的前端下載記錄、離線工作、然後重新連接來提交變化。ADO.NET是WinForms應用程序、ASP.NET應用程序和Web services的一個共有的特點。其功能可以跨LAN和Internet連接來實現，可以在有狀態（stateful）和無狀態（stateless）情況下實現。

這就意味着，作爲一個共有的技術，ADO.NET的對象在所有可能的環境中並不是同等強大的。用ADO.NET爲一個富客戶端（rich client）構建一個數據層同爲一個客戶端通常是共享的和重要的實體（如Web服務器）的Web應用程序構建一個數據層並不一樣。

如果你從前是個ADO開發人員，現在已經用ADO.NET了，那麼你可能把數據訪問看做是一個萬能的對象，如Recordset。我們很自然地會將舊的對象模式同新的對象模式匹配起來，並將現有的方法用於.NET應用程序。然而，在ADO環境中的某些好的方法在轉換到ADO.NET環境時就可能並不強大了。而且，看起來很微不足道的ADO.NET對象模式的複雜性可能會導致很糟糕的編程情況、不理想的代碼、甚至是功能不能實現。我將講述在ADO.NET編程中可能會給你帶來麻煩的10個方面，並提供技巧和解決方法來避免它們。

1. 避免Database-Agnostic形式的編程
ADO.NET中的數據訪問是強類型的，就是說在任何時候你都必須瞭解你正在處理的是什麼數據源（data source)。相反，在ADO中，你可以編寫數據訪問代碼（它們充分利用了OLE DB提供者的通用模式），並將基本的數據源只看做是個參數。ADO對象模式提供了唯一的連接和命令對象，它們隱藏了基本的DBMS的特徵。一旦你在Connection對象上設置了Provider屬性，那麼爲SQL Server或Oracle創建一個命令對象就需要同樣的代碼。許多開發人員都通過該功能來使用生產環境外的Access數據庫，以便很快地測試或演示應用程序。

在ADO.NET中是不能這麼做的，因爲在ADO.NET中，至少連接對象必須是特定於數據源的。你不能以一種間接或通用的方式來創建連接，除非你決定運用ADO的數據訪問技術——OLE DB。在ADO.NET中，你可以用OleDbConnection類創建到一個數據庫的連接，這個類可以讓你訪問各種數據源。在.NET託管環境中運用System.Data.OleDb名字空間中的類並不特別有效，因爲它們是用OLE DB來訪問數據的。你只能用OLE DB來訪問那些沒有.NET數據提供者的數據源。

如果你的應用程序必須訪問全異的數據源（而且你知道可能涉及什麼數據源——一個合理的假設），那麼你可以創建一個集中的factory類，它返回一個連接對象，並通過一個通用的接口（IDbConnection接口）來管理這個連接對象。Factory類在內部運用應用程序參數來決定使用什麼.NET數據提供者：' Create the connection
Dim factory As New MyAppConnectionFactory
Dim conn As IDbConnection
conn = factory.CreateConnection(connString)

' Create the command
Dim cmd As IDbCommand = conn.CreateCommand(query)




一旦你得到了一個連接對象，你就可以以database-agnostic的方式來創建和執行一個命令了，而不管使用的數據源是什麼。你可以使用CreateCommand方法並通過IDbCommand接口來引用命令。然後，你可以用IDbCommand接口上的ExecuteReader方法或ExecuteNonQuery方法來執行命令。如果你用ExecuteReader，你就可以得到一個data reader並可以用IDataReader接口來對它進行一般的訪問了。

你不能用一個通用的數據庫編程模式來填充一個DataSet對象。實際上，你不能像創建一個命令那樣以一種間接的方式來創建data adapter對象。原因就是，在有些情況下，data adapter不同於命令對象，它可以在內部隱含地創建一個連接。然而，它必須以一種強類型的方式工作，而且必須知道基本的數據庫服務器是什麼。

2. 運用字符串來串行化擴展的屬性
幾個ADO.NET對象都擁有一個叫做ExtendedProperties的集合。該屬性就像收集貨物（cargo collection）一樣，可以用來存儲任何類型的用戶信息。DataSet、DataTable和DataColumn就是可以提供該數據成員的類。ADO.NET通過運用PropertyCollection類封裝的一個哈希表來實現這個ExtendedProperties屬性。你可以用Add方法將數據插入到集合中。Add方法使用了兩個參數來保存數據——key和value。該方法的原形將參數定義爲通用的對象類型，你可以存儲任何類型的信息。然而，在特殊情況下，你應該特別注意那些被保存爲擴展屬性的對象的類型。

如果你想將包含擴展屬性的ADO.NET對象串行化到XML，最好只用字符串。如果不行，你必須對ADO.NET的內在的serializer的行爲採取對策。

當ADO.NET將一個DataSet對象保存到XML時，ExtendedProperties集合的內容就被串行化到內存中了，但大概是出於性能的原因，ADO.NET運用了ToString方法，而不是XML serializer來實現串行化。更重要的是，當ADO.NET對象被讀回並復原時，ExtendedProperties集合包含的是對象的字符串表現形式，而不是對象本身。

3. 運用具有BLOB字段的ExecuteXmlReader
用於SQL Server的.NET數據提供者（data provider）使用了數據庫提供的XML擴展名，並提供了一個額外的方法（ExecuteXmlReader）來執行查詢。命令對象上的所有的執行者（例如ExecuteReader和ExecuteScaler）都採用不同的方法來得到結果集。ExcecuteReader通過一個託管指針（managed cursor）（data reader）來返回數據，而ExecuteScaler返回結果集中的第一個值，把它作爲一個標量值。ExecuteXmlReader執行查詢，並返回已經綁定到一個XmlTextReader對象的基於XML的輸出流。通過這種方式，你就不需要做額外的工作來以XML的方式加工數據了。要實現這一點，查詢字符串必須返回XML數據。對SQL Server來說，當查詢字符串包含一個FOR XML子句時，就可以實現它。儘管這只是一種可能。

一個不太爲人所知的情況是，要使ExecuteXmlReader工作，讓結果集包含XML數據就足夠了。 下面的查詢方法很好，只要列包含XML格式的文本就行（見圖1）：SELECT data FROM table WHERE key=1




圖1. 查詢XML數據
這個列是個典型的BLOB或ntext字段，其文本顯示爲XML。簡要地看看ExecuteXmlReader方法的內部結構會有助於我們的理解。該方法用ExecuteReader來執行查詢，並從數據提供者得到一個數據流對象。接下來，它將數據流綁定到XmlTextReader類的一個新創建的實例上，這個實例被返回給調用者。連接一直處於忙碌狀態，直到XML reader停止工作。SQL Server提供者是唯一的提供者，它提供了方法讓我們從一個XML reader直接讀取數據，但這種做法更多的是與提供者有關，而與數據庫性能的關係並不大。Oracle支持XML查詢，但Oracle的數據提供者並不支持XML查詢。相比之下，爲OLE DB數據提供者編寫一個ExecuteXmlReader方法並不難（點此下載實例）。

4. 不要設法緩存一個DataView
DataSet和DataTable對象是唯一的包含數據的ADO.NET對象。DataView是一個不能串行化的、輕量級的類，它只代表構建在一個表上的視圖（view）。你可以根據一個表達式或行的狀態來過濾視圖。許多應用程序都需要你管理數據視圖並將它們綁定到數據控件上，如Windows和Web DataGrid控件。一個DataView對象不能緩存數據；它只是緩存了與當前過濾器相匹配的基本的表中的行的索引。緩存索引的順序與當前的排序表達式一致。緩存DataView而不緩存基本的DataTable是不行的。

例如，提供分頁（比如通過運用DataGrid控件）的ASP.NET應用程序通常以一個DataView對象結尾，因爲它支持排序和過濾。在有些情況下（大多是基於性能的原因），你可能決定要緩存數據源。要緩存的對象不能是DataView（它是你實際綁定的對象）。一個DataView只是一種索引，如果沒有基本的DataTable對象，它是沒有用的。

5. 運用Find來讀取一個記錄
通過運用DataTable的Select方法來運行一個內存中的查詢，或在視圖上設置一個過濾器來濾掉與指定標準不匹配的所有的記錄，你就可以讀取一個DataTable對象中的一個特定的行了。你可以通過設置DataView類上的RowFilter屬性來設置一個過濾器。這兩種方法都運用相同的引擎來選擇記錄。它們可以接納一個表達式，對它進行解析並求各個子句的值。DataTable的Select方法返回一個帶有所有相匹配的DataRow對象的數組。RowFilter屬性重建DataView的內部索引來包含所有的（且僅包含）匹配的記錄。然後，應用程序就可以訪問記錄了。這兩種方法在性能上幾乎是一樣的；運用哪種方法取決於環境和個人喜好。例如，如果你用的是數據綁定的控件，如一個DataGrid或DataList，那麼RowFilter就很理想。如果你必須處理一串記錄，那麼Select方法就更好了。

然而，你還可以用另一種方法（仍然是基於DataView的），它是讀取一個表中的記錄的最快的方法。該方法就是用Find：Dim view As DataView
view = New DataView(table)
view.Sort = "orderid"
Dim index As Integer = view.Find(10248)
Dim row As DataRow = view(index).Row




Find方法運用了視圖的當前索引，並將指定的值（或多個值）與形成當前索引的字段匹配起來。在前面的代碼中，值10248與列orderid匹配。如果Sort屬性爲空，且DataTable對象有一個主鍵，那麼就運用主鍵中的列。Find方法返回的是相匹配的第一行的基於0的位置的值。

如果你想返回多個記錄，可以用FindRows的演變形式： view.Sort = "orderid, discount"
Dim keys(1) As Object
keys(0) = 10248
keys(1) = 0
Dim row As DataRow = _
   view(view.Find(keys)).Row




前面的代碼可以讓你通過運用Find的重載方法（帶有一組對象）來匹配多個列的值。

6. 儘可能用預先排序的數據
ADO.NET對象模式使我們可以很容易地實現排序。你可以創建一個DataView對象並設置其Sort屬性；ADO.NET runtime查看新的排序表達式併爲視圖重編索引。該步驟是在內存中實現的，但速度並不快。排序的花費很高，更重要的是，它並不是個線性操作（linear operation）。對一組數據進行排序需要n*log(n)的計算成本，就是說，隨着需要排序的條目數量的增加，直線增加的成本是很大的。因此，你應該限制應用程序中的排序，儘可能地運用預先排序的數據。在Web應用程序中，動態排序對性能的影響是相當大的。既然如此，你就應該設計應用程序，限制對動態排序的需求，並依賴在數據庫服務器中寫死的算法。除非你在用應用程序的一個可以使複雜性低於n*log(n)極限的特殊的功能，否則避免運用手工排序算法，因爲這種算法可能比系統中的算法更糟。