三層架構核心概念
- 表示層 (UI/Presentation Layer)：Web (ASPX) 或 WinForm，負責用戶交互與數據呈現。
- 業務邏輯層 (BLL/Business Logic Layer)：針對具體問題的操作封裝，組合數據層操作形成業務規則。
- 數據訪問層 (DAL/Data Access Layer)：對原始數據（資料庫/文本文件）的 CRUD 操作，為上層提供數據服務。
各層職責邊界
| 層級 | 核心職責 | 判斷標準 |
|---|
| DAL | 純數據操作（增刪改查），無業務邏輯 | 函數功能原子、不可再分 |
| BLL | 組合 DAL 操作，實現業務規則（如「首單自動註冊」） | 包含業務判斷與流程編排 |
| UI | 接收請求、調用 BLL、返回結果 | 無業務邏輯，僅負責交互 |
為什麼需要「中間業務層」？
以登入為例：UI 接收數據 → BLL 格式化、防 SQL 注入 → DAL 執行資料庫匹配。BLL 將 DAL 原子操作組合為業務規則，如購物網站「首單自動註冊」邏輯放在 BLL 最合適。
鐵律：DAL 絕不能出現業務邏輯，保證函數原子性。
ASP.NET 中的三層架構
- 非物理三層，而是邏輯分層，可部署在單機。
- 客戶端不直接訪問資料庫，透過中間層（COM/DCOM）交互。
- 修改業務邏輯只需改中間層，無需更新成千上萬客戶端。
- 開發者可專注核心業務分析設計，簡化維護升級。
三層架構非 .NET 專利，亦非專用於資料庫，而是通用架構設計理念。
優缺點權衡
優點
缺點
- 執行速度較慢：層層調用帶來開銷，不適用於極致性能場景（如在線訂票、炒股）。
- 入門門檻高：代碼量增加，初學者易迷失。
無銀彈，選型需權衡。擅長處理業務規則易變的系統。
實戰：建立三層解決方案
- 新建空白方案
- 添加企業級模板項目：
- 「數據訪問」→ DAL 專案
- 「業務規則」→ BLL 專案
- 「Web用戶界面」→ UI 專案
- 設置專案依賴：UI 依賴 BLL、DAL；BLL 依賴 DAL
- 添加引用：UI 參考 BLL、DAL；BLL 參考 DAL
為什麼用企業級模板而非空項目？ 模板內建策略檢查，如 BLL 中使用 SqlConnection 會產生「策略警告」，提醒違反分層規範，空項目無此能力。
面向對象與實際結合：橋與磚的隱喻
- UI = 橋（需求端）
- BLL = 磚塊（業務組件）
- DAL = 原料（石頭沙子）
UI 直接依賴 DAL 是因為「橋」既需「磚」也需「原料」。實際開發建議先備料（DAL/BLL）再建橋（UI），文中為講解順序調整。
個人經驗建議
- 資料庫設計重視主從表關係，滿足外鍵約束。
- 子表刪除操作謹慎，避免邏輯上主表外鍵在子表無對應值。
- 綜合查詢：先查主表 → 依主表記錄查各子表 → 合併結果集。
- 增刪改：僅操作主表，調用主表 DAL 方法。
