資料存取層 (DAL) 是三層架構中連接業務邏輯層 (BLL) 與資料庫的關鍵。本文系統梳理 DAL 設計面臨的核心問題，並比較主流解決方案優劣，為後續實作奠定決策基礎。
核心問題釐清
- 資料傳遞形式：DataSet、強型別 DataSet、DataReader、自訂實體 (Entity/POCO)、LINQ 實體。各有利弊，影響序列化、效能、型別安全。
- 事務邊界：存儲程序內、DAL 層、BLL 層？建議統一在 BLL 使用 TransactionScope，避免分散。
- 資料庫可攜性：DAL 封裝目的在於未來更換資料庫時僅修改 DAL，但實務上極少發生，不必過度設計。
- 開發門檻：ADO.NET 需深入理解連線、命令、資料讀取器；LINQ to SQL 大幅降低門檻，背後仍以 ADO.NET 運作。
主流方案深度比較
1. ADO.NET 原生 (SqlConnection, SqlCommand, SqlDataReader)
- 優點：完全控制、效能極致、無額外依賴。
- 缺點：樣板代碼極多 (連線開關、參數、讀取迴圈)、易出錯、維護困難。
- 關鍵類別：
SqlConnection, SqlCommand, SqlDataReader, SqlDataAdapter, DataSet。
2. SqlHelper (Microsoft Data Access Application Block)
- 核心靜態方法：
ExecuteNonQuery：執行非查詢 (INSERT/UPDATE/DELETE)，回傳影響列數。ExecuteDataset：回傳 DataSet。ExecuteReader：回傳 SqlDataReader (需自行關閉連線)。ExecuteScalar：回傳單一值 (如 COUNT、IDENTITY)。FillDataset：填充現有 DataSet。
- 優點：封裝連線管理、參數陣列、命令建立，大幅減少重複代碼。
- 缺點：仍需撰寫 SQL 字串、參數手動對應、無強型別、回傳 DataSet 需手動映射實體。
3. 強型別 DataSet (Typed DataSet / .xsd)
- Visual Studio 設計器產生強型別
DataTable、DataRow、TableAdapter。
- 優點：IntelliSense、編譯時期檢查、TableAdapter 封裝 CRUD。
- 缺點：檔案龐大、版本衝突頻繁、序列化開銷大、難以應對複雜查詢。
4. 自訂實體 + LINQ to SQL (本系列採用)
- 實體類別對應資料表，
DataContext 管理追蹤、查詢、提交。
- 支援存儲程序自訂 CRUD、編譯時期查詢檢查、延遲載入。
- 配合 Repository Pattern 隔離資料存取邏輯，利於單元測試。
決策建議
| 專案屬性 | 推薦方案 |
|---|
| 舊系統維護、團隊熟悉 ADO.NET、極致效能需求 | SqlHelper + 自訂實體映射 |
| 新專案、SQL Server、中大型、領域模型豐富 | LINQ to SQL / Entity Framework Core |
| 跨資料庫、微服務、長期演進 | Entity Framework Core / Dapper |
| 簡單 CRUD、快速原型 | 強型別 DataSet / SqlHelper |
總結
DAL 選型無銀彈，需依團隊技術棧、專案規模、效能需求、長期演進策略綜合判斷。本系列採用 LINQ to SQL + Repository Pattern，平衡開發效率、型別安全與資料庫邏輯控制彈性。
