.NET 資料訪問體繫結構指南一

 

ADO.NET 引入的主要變化之一是用 DataTable、DataSet、DataAdapter 和 DataReader 對象的組合取代了 ADO Recordset 對象。DataTable 表示單個表中行的集合，在這一方面類似於 Recordset。DataSet 表示 DataTable 對象的集合，同時包括將各種表綁定在一起的關係和約束。實際上，DataSet 是帶有內建 XML 支援的、記憶體中的關係結構。

DataSet 的主要特性之一是它不瞭解可能用來填充它的基礎資料來源。它是一個不連續的、獨立的實體，用於表示資料集合，並且可以通過多層應用程式的不同層在組件之間傳遞。它還可以作為 XML 資料流進行序列化，這使其非常適合於在不同種類的平台之間進行資料轉送。ADO.NET 使用 DataAdapter 對象將資料傳送到 DataSet 和基礎資料來源，或者從資料來源傳出。DataAdapter 對象還提供以前與 Recordset 關聯的增強批次更新功能。

ADO.NET 依賴於 .NET 資料提供者的服務。這些提供者提供對基礎資料來源的訪問，並且包括四個主要對象（Connection、Command、DataReader 和 DataAdapter）。

目前，ADO.NET 隨附了兩類提供者：Bridge 提供者和 Native 提供者。通過 Bridge 提供者（如那些為 OLE DB 和 ODBC 提供的提供者），可以使用為以前的資料訪問技術設計的資料庫。Native 提供者（如 SQL Server 和 Oracle 提供者）通常能夠提供效能方面的改善，部分原因在於少了一個抽象層。

命名空間組織圖

與各個 .NET 資料提供者相關聯的類型（類、結構、枚舉等）位於其各自的命名空間中：

•	System.Data.SqlClient。包含 SQL Server .NET 資料提供者類型。
•	System.Data.OracleClient。包含 Oracle .NET 資料提供者。
•	System.Data.OleDb。包含 OLE DB .NET 資料提供者類型。
•	System.Data.Odbc。包含 ODBC .NET 資料提供者類型。
•	System.Data。包含獨立於提供者的類型，如 DataSet 和 DataTable。

在各自的關聯命名空間內，每個提供者都提供了對 Connection、Command、DataReader 和 DataAdapter 對象的實現。SqlClient 實現的首碼為“Sql”，而 OleDb 實現的首碼為“OleDb”。例如，Connection 對象的 SqlClient 實現是 SqlConnection，而 OleDb 實現則為 OleDbConnection。同樣，DataAdapter 對象的兩個實現分別為 SqlDataAdapter 和 OleDbDataAdapter。

預存程序與直接 SQL

本文檔中顯示的大多數程式碼片段使用 SqlCommand 對象來調用預存程序，以執行資料庫操作。在某些情況下，您將不會看到 SqlCommand 對象，因為預存程序名被直接傳遞給 SqlDataAdapter 對象。在內部，這仍然會導致建立 SqlCommand 對象。

您應該使用預存程序而不是嵌入的 SQL 陳述式，原因如下：

•	預存程序通常可以改善效能，因為資料庫能夠最佳化預存程序使用的資料訪問計劃，並且能夠緩衝該計劃以供將來重用。
•	可以在資料庫內分別設定各個預存程序的安全保護。用戶端不必對基礎資料表擁有存取權限，就可以獲得執行預存程序的許可權。
•	預存程序可以簡化維護工作，因為修改預存程序通常要比更改已部署組件中的寫入程式碼 SQL 陳述式容易。
•	預存程序為基礎資料庫結構描述增加了額外的抽象層級。預存程序的用戶端與預存程序的實現細節是彼此隔離的，與基礎架構也是彼此隔離的。
•	預存程序可以減少網路流量，因為可以批量執行 SQL 陳述式，而不是從用戶端發送多個請求。

SQL Server 聯機文檔強烈建議您不要使用“sp_”作為名稱首碼來建立任何預存程序，因為此類名稱已經被指定給系統預存程序。SQL Server 始終按以下順序來尋找以 sp_ 開頭的預存程序：

1.	在主要資料庫中尋找預存程序。
2.	基於所提供的任何限定符（資料庫名或所有者）來尋找預存程序。
3.	使用 dbo 作為所有者來尋找預存程序（如果未指定所有者）。

 

屬性與建構函式參數

可以通過建構函式參數來設定 ADO.NET 對象的特定屬性值，也可以直接設定屬性值。例如，下面的程式碼片段在功能上是等效的。

// Use constructor arguments to configure command objectSqlCommand cmd = new SqlCommand( "SELECT * FROM PRODUCTS", conn );// The above line is functionally equivalent to the following// three lines which set properties explicitlysqlCommand cmd = new SqlCommand();cmd.Connection = conn;cmd.CommandText = "SELECT * FROM PRODUCTS";

從效能角度看，這兩種方法之間的差異是微不足道的，因為針對 .NET 對象設定和擷取屬性要比針對 COM 物件執行類似操作更為高效。

選擇哪種方法取決於個人喜好和編碼風格。不過，對屬性進行明確設定確實能夠使代碼更易理解（尤其是當您不熟悉 ADO.NET 物件模型時）和調試。

管理資料庫串連

資料庫連接代表一種關鍵的、昂貴的和有限的資源，尤其是在多層 Web 應用程式中。正確地管理串連是十分必要的，因為您採取的方法可能顯著影響應用程式的總體延展性。同時，還要認真考慮在何處儲存連接字串。需要使用可配置的且安全的位置。

在管理資料庫串連和連接字串時，應該努力做到：

•	通過在多個用戶端中多工資料庫連接池，協助實現應用程式的延展性。
•	採用可配置的、高效能的串連池策略。
•	在訪問 SQL?Server 時使用 Windows 身分識別驗證。
•	在中介層避免類比。
•	安全地儲存連接字串。
•	盡量晚地開啟資料庫連接，盡量早地將其關閉。

本節討論串連池，並且協助您選擇適當的串連池策略。本節還將考慮應該如何管理、儲存和操縱資料庫連接字串。最後，本節將給出兩種編碼模式，可用來協助確保串連被可靠地關閉，並被返回到串連池。

SQL Server .NET 資料提供者的池機制

如果您使用的是 SQL Server .NET 資料提供者，請使用該提供者提供的串連池支援。這是一種由該提供者在內部實現的支援交易處理並且非常高效的機制，它存在於Managed 程式碼中。池是以每個應用程式的域為基礎建立的，並且在應用程式定義域卸載之前不會銷毀。

可以透明地使用這種形式的串連池，但應該知道池的管理方式以及可用來微調串連池的各種配置選項。

在許多情況下，對於您的應用程式而言，SQL Server .NET 資料提供者的預設串連池設定可能已經足夠了。在開發與測試基於 .NET 的應用程式的過程中，建議您對規劃通訊模式進行類比，以確定是否需要修改串連池大小。

需要產生可伸縮的高效能應用程式的開發人員應該最大限度地減少使用串連的時間，只在檢索或更新資料時才使串連保持開啟狀態。串連關閉時，將被返回到串連池，並可供重用。在此情況下，到資料庫的實際串連不會被切斷；不過，如果串連池被禁用，則到資料庫的實際串連將被關閉。

開發人員應該十分小心，不要依賴記憶體回收行程來釋放串連，因為當引用離開作用範圍時，串連未必能夠關閉。這是串連泄漏的一種常見根源，當請求新串連時，這會導致串連異常。

配置 SQL Server .NET 資料提供者串連池

可以使用一組名稱-值對（通過連接字串提供）來配置串連池。例如，可以配置是否啟用串連池（預設情況下啟用）、池的最大容量和最小容量，以及要開啟串連的排隊請求可以阻塞的時間長度。下面是一個樣本連接字串，用於配置池的最大容量和最小容量。

"Server=(local); Integrated Security=SSPI; Database=Northwind; Max Pool Size=75; Min Pool Size=5"

開啟串連並建立池以後，會將多個串連添加到池中，以便將串連數量提高到所配置的最小數量。隨後，可以繼續向該池中添加串連，直至達到所配置的最大池數量。當達到最大數量時，要開啟串連的新請求將排隊等待一段可配置的時間。

更多資訊

當使用 SQL Server .NET 資料提供者串連池時，請注意以下幾個方面：

•	串連是通過連接字串上的完全符合演算法進行池化的。池機制甚至對名稱-值對之間的空格也敏感。例如，下面的兩個連接字串將導致兩個獨立的池，因為第二個連接字串包含額外的空白字元。 SqlConnection conn = new SqlConnection( "Integrated Security=SSPI;Database=Northwind");conn.Open(); // Pool A is createdSqlConmection conn = new SqlConnection( "Integrated Security=SSPI ; Database=Northwind");conn.Open(); // Pool B is created (extra spaces in string)
•	串連池被劃分為多個事務專有池和一個與當前尚未在事務中登記的串連對應的池。對於與特定事務上下文關聯的線程，會返回相應池（該池包含在該事務中登記的串連）的串連。這就使得使用已登記的串連成為一個透明的過程。

 

OLE DB .NET 資料提供者的池機制

OLE DB .NET 資料提供者通過使用基礎 OLE DB 資源集區來池化串連。有多個用於配置資源集區的選擇：

•	可以使用連接字串來配置、啟用或禁用資源集區。
•	可以使用註冊表。
•	可以用編程方式配置資源集區。

為避免出現與註冊表相關的部署問題，請不要使用註冊表來配置 OLE DB 資源集區。

監控串連池

要對應用程式使用串連池的情況進行監控，可以使用 SQL Server 隨附的事件探查器工具，或者使用 Microsoft Windows? 2000 作業系統隨附的效能監控器工具。

使用 SQL Server 事件探查器監控串連池

1.	單擊 Start，指向 Programs，指向 MicrosoftSQLServer，然後單擊 Profiler 以啟動事件探查器。
2.	在 File 菜單上，指向 New，然後單擊 Trace。
3.	提供串連詳細資料，然後單擊 OK。
4.	在 Trace Properties 對話方塊中，單擊 Events 選項卡。
5.	在 Selected event classes 列表中，確保 Audit Login 和 Audit Logout 事件顯示在 Security Audit 下面。要使跟蹤變得更為清晰，請從該列表中刪除所有其他事件。
6.	單擊 Run 以啟動跟蹤。當串連建立時，您將看到 Audit Login 事件；當串連關閉時，您將看到 Audit Logout 事件。

使用效能監控器監控串連池

1.	單擊 Start，指向 Programs，指向 Administrative Tools，然後單擊 Performance 以啟動效能監控器。
2.	按右鍵圖形背景，然後單擊 AddCounters。
3.	在 Performance object 下拉式清單中，單擊 SQL Server:General Statistics。
4.	在顯示的列表中，單擊 User Connections。
5.	單擊 Add，然後單擊 Close。

 

管理安全性

儘管資料庫連接池提高了應用程式的總體延展性，但這意味著您不再能夠在資料庫層級管理安全性。這是因為，要支援串連池，連接字串必須完全相同。如果您需要跟蹤每個使用者的資料庫操作，請考慮添加一個參數，以便能夠傳遞使用者標識並在資料庫中手動記錄使用者操作。您需要將該參數添加到每個操作中。

使用 Windows 身分識別驗證

在串連到 SQL Server 時，應該使用 Windows 身分識別驗證，因為它提供了許多好處：

1.	安全性更易於管理，因為您使用單一 (Windows) 安全模型，而不是獨立的 SQL Server 安全模型。
2.	可避免將使用者名稱和密碼嵌入到連接字串中。
3.	不會以明文方式通過網路傳遞使用者名稱和密碼。
4.	通過採用密碼到期期限、最小長度以及在多次無效登入請求後鎖定帳戶，改善了登入安全性。

 

儲存連接字串

要儲存資料庫連接字串，可以有多種選擇，這些選擇具有不同層級的靈活性和安全性。儘管在原始碼中對連接字串進行寫入程式碼可提供最佳效能，但檔案系統快取可確保在外部將該字串儲存到檔案系統中所帶來的效能下降是微不足道的。幾乎在所有情況下，人們都首選外部連接字串所提供的額外的靈活性（它支援管理員配置）。

當您選擇連接字串儲存方法時，需要注意的兩個最重要的事項是安全性和配置簡易性，然後緊跟著的是效能。

可以選擇下列位置來儲存資料庫連接字串：

•	在應用程式設定檔中；例如，ASP.NET Web 應用程式的 Web.config
•	在通用資料連結 (UDL) 檔案中（僅由 OLE DB .NET 資料提供者支援）
•	在 Windows 註冊表中
•	在自訂檔案中
•	在 COM+ 目錄中，方法是使用構建字串（僅適用於服務元件）

通過使用 Windows 身分識別驗證來訪問 SQL Server，可以避免將使用者名稱和密碼儲存在連接字串中。如果您的安全要求需要採取更嚴格的措施，請考慮以加密格式儲存連接字串。

對於 ASP.NET Web 應用程式而言，在 Web.config 檔案內以加密格式儲存連接字串，代表著一種安全的、可配置的解決方案。

注 可以在連接字串中將 Persist Security Info 命名值設定為 false，以禁止通過 SqlConnection 或 OleDbConnection 對象的 ConnectionString 屬性返回對安全敏感的細節（如密碼）。

下面幾小節討論了如何使用各種選擇來儲存連接字串，並介紹了各種方法的相對優點和缺點。這些內容有助於您根據自己特定的應用程式方案做出明智的選擇。

使用 XML 應用程式設定檔

可以使用 <appSettings> 元素在應用程式設定檔的自訂設定節中儲存資料庫連接字串。該元素支援任意的密鑰-值對，如以下程式碼片段所示：

<configuration> <appSettings>  <add key="DBConnStr"     value="server=(local);Integrated Security=SSPI;database=northwind"/> </appSettings></configuration>

注 <appSettings> 元素出現在 <configuration> 元素下面，並且不是緊跟在 <system.web> 的後面。

優點

•	易於部署。連接字串是通過定期 .NET xcopy 部署與設定檔一起部署的。
•	易於以編程方式訪問。通過 ConfigurationSettings 類的 AppSettings 屬性，可以在運行時方便地讀取已配置的資料庫連接字串。
•	支援動態更新（僅限於 ASP.NET）。如果管理員在 Web.config 檔案中更新連接字串，當下一次訪問該字串時（對於無狀態組件而言，這可能是用戶端下一次使用該組件進行資料訪問請求），所做更改將生效。

缺點

•	安全性。儘管 ASP.NET 網際網路服務器API (ISAPI) 動態連結程式庫 (DLL) 禁止用戶端直接存取帶有 .config 副檔名的檔案，並且可以使用 NTFS 許可權進一步限制訪問，您可能仍然希望避免以明文形式在前端網頁伺服器上儲存這些詳細資料。為獲得額外的安全性，請以加密格式在設定檔中儲存連接字串。

 

可以使用 System.Configuration.ConfigurationSettings 類的靜態 AppSettings 屬性來檢索自訂應用程式設定。以下程式碼片段對此進行了說明，該程式碼片段採用了前面例舉的名為 DBConnStr 的自訂密鑰：

using System.Configuration;private string GetDBaseConnectionString(){  return ConfigurationSettings.AppSettings["DBConnStr"];}

 

作者Blog：http://blog.csdn.net/yangyifan0/