濫用三層的慘痛教訓
許多項目號稱三層，實則將業務邏輯塞入數據訪問層（DAL），導致維護困難、事務控制混亂。作者以親身經歷的幾個項目（如 ungou.com、yinggou.com、doocn.com）為例，指出「三層失敗」的典型癥狀：代碼混亂、業務變更牽一髮動全身。
重新定義三層職責
數據訪問層（DAL）：純粹的「積木」
- 僅提供增刪改查、判斷存在等通用數據操作，不包含業務事務。
- 業務需求變更不應導致 DAL 修改（除非表結構變動）。
- 方法職責單一、穩定，適合代碼生成。
- 可檢測當前線程事務上下文：有事務則加入，無則自建連接。
業務邏輯層（BLL）：搭建積木的「架構師」
- 核心任務：按業務需求組合調用 DAL 方法，控制事務邊界。
- 例：添加用戶 → 開啟事務 → 插入用戶 → 寫操作日誌 → 提交事務。
- 需求變更（如增加角色分配）只需調整 BLL 組合邏輯，DAL 不動。
表現層：暫不贅述
基於此設計的優缺點
優點
- DAL 粒度細、通用性強、極其穩定，適合代碼生成。
- BLL 靈活承載核心業務邏輯，代碼量大但清晰，非單純「轉發器」。
缺點與對策
- 事務在 BLL 可能導致多數據庫支持困難（主流數據庫均支持事務，風險低）。
- DAL 需判斷事務上下文，增加複雜度。可引入 Spring.NET 等框架統一管理事務，降低層間耦合。
主流框架的「反面教材」
- PetShop 4：事務未下沉至 BLL，價值未體現。
- DiscuzNT：事務混雜在 DAL，代碼生成工具難用，業務變更雙層皆改。文中列出超長存儲過程移動版塊代碼為證。
- 動軟代碼生成器：生成代碼同樣將事務置於 DAL，導致 DAL 不穩定、BLL 淪為轉發器。
核心呼籲
缺乏優雅的 BLL 事務控制機制是框架誤入歧途的主因。引入 Spring.NET 等成熟框架，或自行封裝事務上下文管理，是走出泥潭的關鍵。歡迎同行拋磚引玉。
