JDBC 分層架構實戰：財務帳號 DAO 設計模式與持久層最佳實踐

JDBC 分層架構實戰：財務帳號 DAO 設計模式與持久層最佳實踐

企業級應用普遍採用「表現層 + 控制層 + 業務層 + **持久層 (DAO)** + 數據源」分層架構。本文闡述 DAO (Data Access Object) 模式核心思想、職責邊界、事務控制分層策略，並給出財務帳號管理的 DAO 接口設計規範。

DAO 模式核心價值

• 封裝數據訪問細節：連接獲取、SQL 構建/執行、結果集映射、資源關閉、異常轉換，對上層業務透明。
• 解耦業務邏輯與數據存儲：業務層面向接口編程，不依賴具體 SQL、表結構、數據庫類型，便於單元測試 (Mock DAO) 與遷移 (MySQL → Oracle/PostgreSQL)。
• 複用與組合：簡單業務調用單個 DAO 方法；複雜業務在 Service 層組合多個 DAO 方法，**事務邊界在 Service 層控制**，而非 DAO 內部，保證 DAO 粒度可複用。

分層職責劃分

財務帳號 DAO 接口設計規範

public interface FinanceAccountDao {
    // 1. 新增財務帳號
    long insert(FinanceAccount account);

    // 2. 修改帳號基本信息 (除狀態外)
    int updateInfo(FinanceAccount account);

    // 3. 修改帳號狀態 (啟用/停用/凍結)
    int updateStatus(Long accountId, AccountStatus status);

    // 4. 查詢所有帳號 (分頁)
    List<FinanceAccount> selectPage(int pageNum, int pageSize);

    // 5. 根據 ID 查詢帳號詳情
    FinanceAccount selectById(Long accountId);

    // 6. 根據條件動態查詢 (可選)
    List<FinanceAccount> selectByCondition(FinanceAccountQuery query);
}

關鍵實現要點

1. 實體類：FinanceAccount 包含 id、account_no、account_name、balance、status、create_time、update_time 等字段，對應表列。
2. 動態 SQL 構建：更新方法僅更新非空字段 (MyBatis `` / 手動拼接)，避免全列更新覆蓋並發修改。
3. 異常轉換：捕獲 SQLException，包裝為 DaoException (RuntimeException) 拋出，Service 層統一處理。
4. 連接管理：從 ThreadLocal / Spring 管理的事務連接獲取 Connection，**不在 DAO 中開啟/提交/關閉事務**。
5. 分頁實現：MySQL LIMIT ?, ? + COUNT(*) 統計總數；大偏移量優化採用「游標/ID 下標」模式。

事務控制反模式與正確姿勢

❌ 錯誤：在 DAO 方法內部 con.setAutoCommit(false) / commit()。導致：多 DAO 組合時無法保證原子性、DAO 無法複用、連接洩漏風險。

✅ 正確：Service 方法加 @Transactional (Spring) 或手動控制 Connection 事務，調用多個 DAO 方法：

@Transactional
public void transfer(Long fromId, Long toId, BigDecimal amount) {
    FinanceAccount from = dao.selectById(fromId);
    FinanceAccount to = dao.selectById(toId);
    // 業務校驗...
    from.setBalance(from.getBalance().subtract(amount));
    to.setBalance(to.getBalance().add(amount));
    dao.updateInfo(from); // 同一事務
    dao.updateInfo(to);   // 同一事務
}

總結

DAO 是持久層的「門面」，職責單一：SQL 執行與對象映射。事務、緩存、鎖、幂等性等橫切關注點屬於 Service 或基礎設施層。良好的分層讓代碼可測、可維、可擴展。