EJB 應用中資料驗證邏輯的最佳放置策略

驗證分類：格式驗證 vs 業務驗證

在決定驗證代碼放置位置前，必須區分兩類驗證：

• 資料格式驗證：確保型別正確、數值範圍、模式匹配等，不涉及業務規則（如 ISBN 格式、Email 格式）。
• 業務規則驗證：依賴具體業務邏輯與資料存取（如 ISBN 是否存在於資料庫、用戶信用額度是否足夠）。

資料格式驗證：越靠近客戶端越好

格式驗證錯誤通常直接回饋給用戶（重新輸入），追求最低處理開銷、最快回應。在採用業務委派模式的 EJB 架構中，委派類是 Web 層與 EJB 層的門面，放置格式驗證最自然：

public class LibraryDelegate implements ILibrary {
    public boolean checkout(List books) throws ApplicationException {
        // 格式驗證：確保列表元素皆為 Book
        for (Iterator i = books.iterator(); i.hasNext(); ) {
            Object obj = i.next();
            if (!(obj instanceof Book)) {
                throw new ApplicationException(VALIDATION_ERROR, "Only Books allowed");
            }
        }
        return library.checkout(books); // 委派給 Session Bean
    }
}

優勢：錯誤直接在委派層拋回 Web 層，避免 JNDI 查找、RMI 傳輸、Session Bean 進入等昂貴開銷。

業務驗證：下沉至 EJB 核心層

業務驗證涉及多實體協作、資料庫查詢、事務邊界，若放在委派層：

• 需將大量業務邏輯上移，破壞分層。
• 遠端介面調用開銷大（序列化、網路）。

最佳位置是 Session Bean 實作類（或領域模型）：

• Bean 之間透過本地介面調用，容器內 JVM 優化，極低延遲。
• 已完成 JNDI 查找、事務上下文建立。
• 委派層已過濾格式錯誤，Bean 專注核心業務規則。

分層驗證架構圖解

反模式警示

1. 重複驗證：多層重複同樣邏輯 → 維護惡夢，除非極少數安全關鍵點雙重檢查。
2. 業務驗證上浮：委派層查詢資料庫 → 破壞分層、效能差。
3. 格式驗證下沉：Bean 做正則匹配 → 浪費事務資源、擾亂核心邏輯。

結語

「格式驗證前置，業務驗證後置」是經驗法則。利用委派模式天然的分層邊界，讓錯誤在最經濟的層級被攔截，讓業務邏輯在最高效的層級執行，是 EJB 應用驗證架構的核心智慧。