.NET的數(shù)據(jù)訪問編程模式需要一套新的技巧和最佳方法。
by Dino Esposito
技術(shù)工具箱：VB.NET、SQL Server 2000、XML
ADO.NET提供了一個統(tǒng)一的編程模式和一組公用的類來進(jìn)行任何類型的數(shù)據(jù)訪問，而不管你用何種語言來開發(fā)代碼。ADO.NET是全新的，但又與ADO盡可能保持一致，它使編程模式從一個客戶端/服務(wù)器、基于連接的模式轉(zhuǎn)變到了一個新的模式，這個新模式可以讓斷開的前端下載記錄、離線工作、然后重新連接來提交變化。ADO.NET是WinForms應(yīng)用程序、ASP.NET應(yīng)用程序和Web services的一個共有的特點。其功能可以跨LAN和Internet連接來實現(xiàn)，可以在有狀態(tài)（stateful）和無狀態(tài)（stateless）情況下實現(xiàn)。

這就意味著，作為一個共有的技術(shù)，ADO.NET的對象在所有可能的環(huán)境中并不是同等強大的。用ADO.NET為一個富客戶端（rich client）構(gòu)建一個數(shù)據(jù)層同為一個客戶端通常是共享的和重要的實體（如Web服務(wù)器）的Web應(yīng)用程序構(gòu)建一個數(shù)據(jù)層并不一樣。

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

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

在ADO.NET中是不能這么做的，因為在ADO.NET中，至少連接對象必須是特定于數(shù)據(jù)源的。你不能以一種間接或通用的方式來創(chuàng)建連接，除非你決定運用ADO的數(shù)據(jù)訪問技術(shù)——OLE DB。在ADO.NET中，你可以用OleDbConnection類創(chuàng)建到一個數(shù)據(jù)庫的連接，這個類可以讓你訪問各種數(shù)據(jù)源。在.NET托管環(huán)境中運用System.Data.OleDb名字空間中的類并不特別有效，因為它們是用OLE DB來訪問數(shù)據(jù)的。你只能用OLE DB來訪問那些沒有.NET數(shù)據(jù)提供者的數(shù)據(jù)源。

如果你的應(yīng)用程序必須訪問全異的數(shù)據(jù)源（而且你知道可能涉及什么數(shù)據(jù)源——一個合理的假設(shè)），那么你可以創(chuàng)建一個集中的factory類，它返回一個連接對象，并通過一個通用的接口（IDbConnection接口）來管理這個連接對象。Factory類在內(nèi)部運用應(yīng)用程序參數(shù)來決定使用什么.NET數(shù)據(jù)提供者：' 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的方式來創(chuàng)建和執(zhí)行一個命令了，而不管使用的數(shù)據(jù)源是什么。你可以使用CreateCommand方法并通過IDbCommand接口來引用命令。然后，你可以用IDbCommand接口上的ExecuteReader方法或ExecuteNonQuery方法來執(zhí)行命令。如果你用ExecuteReader，你就可以得到一個data reader并可以用IDataReader接口來對它進(jìn)行一般的訪問了。

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

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

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

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

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

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




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

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

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

5. 運用Find來讀取一個記錄
通過運用DataTable的Select方法來運行一個內(nèi)存中的查詢，或在視圖上設(shè)置一個過濾器來濾掉與指定標(biāo)準(zhǔn)不匹配的所有的記錄，你就可以讀取一個DataTable對象中的一個特定的行了。你可以通過設(shè)置DataView類上的RowFilter屬性來設(shè)置一個過濾器。這兩種方法都運用相同的引擎來選擇記錄。它們可以接納一個表達(dá)式，對它進(jìn)行解析并求各個子句的值。DataTable的Select方法返回一個帶有所有相匹配的DataRow對象的數(shù)組。RowFilter屬性重建DataView的內(nèi)部索引來包含所有的（且僅包含）匹配的記錄。然后，應(yīng)用程序就可以訪問記錄了。這兩種方法在性能上幾乎是一樣的；運用哪種方法取決于環(huán)境和個人喜好。例如，如果你用的是數(shù)據(jù)綁定的控件，如一個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方法運用了視圖的當(dāng)前索引，并將指定的值（或多個值）與形成當(dāng)前索引的字段匹配起來。在前面的代碼中，值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. 盡可能用預(yù)先排序的數(shù)據(jù)
ADO.NET對象模式使我們可以很容易地實現(xiàn)排序。你可以創(chuàng)建一個DataView對象并設(shè)置其Sort屬性；ADO.NET runtime查看新的排序表達(dá)式并為視圖重編索引。該步驟是在內(nèi)存中實現(xiàn)的，但速度并不快。排序的花費很高，更重要的是，它并不是個線性操作（linear operation）。對一組數(shù)據(jù)進(jìn)行排序需要n*log(n)的計算成本，就是說，隨著需要排序的條目數(shù)量的增加，直線增加的成本是很大的。因此，你應(yīng)該限制應(yīng)用程序中的排序，盡可能地運用預(yù)先排序的數(shù)據(jù)。在Web應(yīng)用程序中，動態(tài)排序?qū)π阅艿挠绊懯窍喈?dāng)大的。既然如此，你就應(yīng)該設(shè)計應(yīng)用程序，限制對動態(tài)排序的需求，并依賴在數(shù)據(jù)庫服務(wù)器中寫死的算法。除非你在用應(yīng)用程序的一個可以使復(fù)雜性低于n*log(n)極限的特殊的功能，否則避免運用手工排序算法，因為這種算法可能比系統(tǒng)中的算法更糟。