專案背景與開發節奏
參與一個為期一個月的 Struts 管理系統專案，經歷從環境搭建、業務熟悉、計劃制定到功能交付的完整週期。開發流程遵循經典分層架構：VO → DAO → DAO 測試 → BO → BO 測試 → JSP → ActionForm → Action，本文複盤各層關鍵實踐與踩坑記錄。
各層核心實踐總結
1. Value Object (VO) - 數據載體
- 結構與 FormBean 高度相似，差別在於層次：VO 對應資料庫表，屬性映射欄位類型。
- 痛點：資料庫
DATE 類型映射至 Java java.util.Date 或 java.sql.Date 時，格式轉換、時區、截取時分秒極易出錯，需統一工具類處理。
2. Data Access Object (DAO) - 持久化入口
- 所有 DAO 繼承
BasicDAO，封裝通用 CRUD 與查詢模板方法。
- 線程安全：DAO 為無狀態單例，採用 Singleton 模式（雙重檢查鎖或靜態內部類）確保全局唯一實例，避免併發下連接洩漏或狀態汙染。
3. Business Object (BO) - 業務協調層
- BO 組合 DAO 接口，對外暴露粗粒度業務方法（
update、delete 等）。
- 本專案業務較簡單（以增刪改查為主），BO 層未體現複雜事務編排與領域邏輯封裝的價值，但分層結構仍利於日後擴展。
4. JUnit 單元測試 - 質量保障
- 測試類繼承
junit.framework.TestCase，核心模板：setUp() 初始化、tearDown() 清理、testXXX() 具體測試邏輯。
- 重點測試 DAO/BO 邊界條件、事務回滾、異常拋出場景。
5. ActionForm 與 Action - Web 請求處理
- 利用 JBuilder 從 JSP 反向生成 ActionForm，再生成 Action 骨架，大幅提升效率。
- Action 僅負責參數收集、委派 BO、結果轉發，不含業務邏輯。
專案級配置經驗
- Struts-config.xml 模組化：按功能模組拆分配置文件，主文件
<include> 引入，降低衝突與維護成本。
- 國際化資源：
ApplicationResources.properties 統一管理標籤、錯誤訊息，支援多語言擴展。
- 異常處理：配置
<global-exceptions> 統一導向友好錯誤頁，避免堆疊跡露出給用戶。
心得與建議
- 分層紀律：嚴禁 JSP/Action 直接調用 DAO 或 JDBC，保持 BO 為業務唯一入口。
- VO 不可變化：建議 VO 設計為不可變物件（final 屬性 + 建構子注入），減少副作用。
- 測試先行：DAO/BO 開發同步編寫單元測試，集成測試前保證單元綠燈。
- 工具輔助：善用 IDE 代碼生成、重構功能，但需理解生成代碼語義，不可盲目依賴。
這個月的實戰讓我從「書本懂 Struts」進化為「能用 Struts 做系統」，核心在於嚴守分層架構、重視測試驅動、善用配置而非硬編碼。
