關鍵字：SQL Server數據庫編寫通用數據訪問在負責咨詢工作的過去 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），且編寫高效的應用程序仍然必須使用這些特定特征而不是“共同點”。從可移植性觀點看來，托管和非托管的數據訪問技術仍然非常類似。
除“利用數據源的唯一特征”外，編寫良好數據訪問層所必需的其他規則對每個數據源通常都是相同的：
• 在可能的情況下使用連接池機制。
文章來源于領測軟件測試網 http://www.kjueaiud.com/