IDesign C# 編碼標準（五）：資料存取與 Framework 專項指導原則

資料存取層設計鐵律

IDesign 編碼標準第 4 章針對 .NET Framework 特定領域提出強制性指導原則，資料存取部分共 8 條鐵律：

1. 強型別資料集／資料表

// ✅ 推薦
var ds = new StrongTypedDataSet();
var dt = ds.Customers;

// ❌ 禁止：原始 ADO.NET DataSet/DataTable
var ds = new DataSet();
var dt = ds.Tables["Customers"];

強型別提供編譯期檢查、IntelliSense 支援、避免字串索引錯誤。

2. 資料庫操作必須使用交易

所有資料庫寫入操作（Insert/Update/Delete）均須包裹在交易中。

3. 交易實作必須使用 Enterprise Services (COM+) 交易

[Transaction(TransactionOption.Required)]
public class OrderService : ServicedComponent
{
    public void PlaceOrder(Order order) { ... }  // 自動交易管理
}

嚴禁 使用 ADO.NET 手動交易（SqlTransaction、BeginTransaction）。

4. 交易隔離層級強制設為 Serializable

最高隔離層級，防止髒讀、不可重複讀、幻讀。若需降低隔離層級，必須經管理層審核決策。

5. 禁止使用伺服器總管拖曳資料庫連線至 UI 層

// ❌ 禁止：將連線元件拖曳到 Windows Form / ASP.NET 網頁 / Web Service
// 這會導致「表現層」直接耦合「資料層」

資料存取邏輯必須封裝在獨立組件（Business Logic Layer / Data Access Layer）。

6. 避免 SQL Server 驗證，改用 Windows 整合驗證

• 連接字串使用 Integrated Security=SSPI 或 Trusted_Connection=True
• 避免在連接字串或設定檔明文儲存帳號密碼

7. 存取 SQL Server 的元件應以不同於呼叫端的身分執行

應用程式集區身分、COM+ 應用程式身分、服務帳戶應遵循最小權限原則，與前端使用者身分隔離。

8. 預存程序必須由高層強型別類別封裝，禁止在預存程序放置商業邏輯

// ✅ 推薦：Repository 模式封裝預存程序
public class CustomerRepository
{
    public Customer GetById(int id)
    {
        using (var cmd = new SqlCommand("usp_GetCustomer", conn))
        {
            cmd.CommandType = CommandType.StoredProcedure;
            cmd.Parameters.AddWithValue("@Id", id);
            // 執行並映射至強型別實體
        }
    }
}

// ❌ 禁止：預存程序包含 IF/ELSE 商業邏輯
/* 
CREATE PROC usp_BadExample
AS
IF @Amount > 1000 BEGIN ... END ELSE BEGIN ... END  -- 商業邏輯洩漏到資料層
*/

判斷準則：若預存程序出現 IF、CASE、WHILE 等流程控制，通常代表商業邏輯錯置。

架構師隨筆：Business Layer 存在的必要性

「有多少專案真正擁有 Business Layer？甚至建議 Presentation Layer 完全不引用 System.Data 命名空間。你做得到嗎？」

這是對分層架構純度的挑戰。真正的分層意味著：

• UI 層只認識領域模型（DTO/Entity）與服務介面
• 資料存取細節（Connection、Command、DataReader）完全隔離在 DAL
• 商業規則、工作流程、驗證邏輯集中在 BLL

雖然理想很豐滿，現實常因時程壓力妥協。但作為架構師，應持續推動依賴反轉、介面導向設計，逐步逼近純粹分層。

下一章預告

續篇將涵蓋：例外處理標準、非同步程式設計規範、記憶體管理指導、安全性編碼規範、測試與文件化要求。