引言
在負責咨詢工作的過去 6 年中，我曾多次聽說關於數據訪問和操作方面的問題，它時刻困擾著用戶：“如何編寫應用程序，以便只需對其進行很少的改動或不進行改動即可使用數據庫服務器 x、y 和 z？”由於知道數據訪問層仍然是現代應用程序的最關鍵部分，並且通常是經驗不足的開發人員的頭號敵人，因此我的第一反應始終是：根本辦不到！
面對著人們惶惶不安的面孔以及“使用 Microsoft 在 ADO 中提供的通用數據訪問方法如何？”這樣的問題，我決定針對此問題提供更詳細的說明以及建議的解決方案。
問題在於，如果應用程序是較小的原型，或者如果並發用戶較少並且數據訪問邏輯比較簡單，那麼即使您選擇下面這些最簡單的方法，也不會遇到任何問題：使用 RAD 工具（如 Data Environment in Microsoft® Visual Basic® 6.0），或某些“一攬子”解決方案（如 ActiveX® Data Control 和其他第三方組件），這些解決方案通常會隱藏應用程序與特定數據源之間進行的復雜交互。然而，當用戶數量增加使得必須解決並發操作問題時，由於頻繁使用動態記錄集、服務器端光標以及不必要的鎖定策略，導致出現許多性能問題。為達到用戶目標而必須對系統所做的設計和代碼更改將花費您大量的時間，因為您從開始時就沒有考慮過這一問題。
使用通用數據訪問方法
在將 ADO 可靠地並入 MDAC（Microsoft Data Access Components 2.1 版）後，Microsoft 掀起了通用數據訪問的使用高潮。其主導思想是向開發人員展示，通過使用簡單的對象模型（“連接”、“命令”和“記錄集”），可以編寫出能夠與各種不同的數據源（無論是關系數據源還是非關系數據源）連接的應用程序。文檔（以及當時的大多數文章和示例）中通常未曾提及的是，即使使用相同的數據訪問技術，各種數據源的可編程性和特征也千差萬別。
其結果是，在需要從多個數據源獲取數據的應用程序中，最簡單的方法是使用所有數據源所提供的功能的“共同點”，但因此會失去使用數據源特定選項的好處，即為訪問和操作各種 RDBMS 中的信息提供最佳方法。
我對該方法始終存在的懷疑是，經過與我的客戶進行更詳細的分析後，我們通常一致認為與應用程序中處理顯示和業務邏輯的其他部分相比，與數據源進行交互的只是應用程序很小的一部分。通過進行精心的模塊化設計，可以將 RDBMS 特定代碼隔離在一些容易互換的模塊中，從而避免對數據訪問使用“通用”方法。然而，我們可以使用非常特定的數據訪問代碼（根據數據源的不同，使用存儲過程、命令批處理和其他特性），而不觸及其他大多數應用程序代碼。這總是提醒大家：正確的設計是編寫可移植的有效代碼的關鍵。
ADO.NET 將一些重要的變化引入到數據訪問編碼領域，如專用 .NET 數據提供程序這樣的概念。使用特定的提供程序，可以繞過為數眾多但有時沒必要的一系列軟件接口和服務（它們是 OLE DB 和 ODBC 層在數據訪問代碼與數據庫服務器之間插入的內容），從而以最佳方式連接到數據源。但每個數據源仍然存在不同的特征和特性（具有不同的 SQL Dialect），且編寫高效的應用程序仍然必須使用這些特定特征而不是“共同點”。從可移植性觀點看來，托管和非托管的數據訪問技術仍然非常類似。
除“利用數據源的唯一特征”外，編寫良好數據訪問層所必需的其他規則對每個數據源通常都是相同的：
• 在可能的情況下使用連接池機制。
• 節約使用數據庫服務器的有限資源。
• 注意網絡的往返。
• 在適當的情況下，增強執行計劃的重復使用率並避免重復編譯。
• 使用適當的鎖定模型管理並發性。
從我使用模塊化設計方法的個人經驗來看，整個應用程序中專用於處理特定數據源的代碼量不會超過總量的 10%。顯而易見，這比僅僅更改配置文件中的連接字符串更復雜，但我認為，這樣做會獲得性能收益，因此這是一個可接受的折衷辦法。
使用基本接口
此處的目標是使用抽象，並將特定於特殊數據源的代碼封裝在類層中，從而使應用程序的其他部分獨立於後端數據庫服務器或免受其影響。
.NET Framework 的面向對象這一特性將在該過程中為我們提供幫助，使我們能夠選擇要使用的抽象級別。選項之一是使用每個 .NET 數據提供程序都必須實現的基本接口（IDbConnection、IDbCommand、IDataReader 等）。另一個選項是創建一組類（數據訪問層），用於管理應用程序的所有數據訪問邏輯（例如，使用 CRUD 范例）。為檢查這兩種可能性，我們首先從基於 Northwind 數據庫的訂單輸入應用程序示例入手，然後插入和檢索不同數據源中的信息。
