資料持久化是企業開發最棘手環節。企業級方案必須：提供快速客戶交易、確保長期資料完整性、在系統崩潰/網路故障時資料倖存。本系列兩集將深度剖析 J2EE 三大持久化技術。本集聚焦：實體 Bean（一站式方案）vs Session Bean + JDBC（更複雜但更健壯的組合）。
什麼是資料持久化？
持久資料存儲 = 即使伺服器崩潰仍存在的資料倉庫。NIST 定義三級持久性：
- 部分持久：僅允許更新最新版本
- 持久：保留舊版本，可查詢歷史版本（企業架構/DBMS 常見）
- 完全持久：維護所有版本並允許更新（極罕見：日誌檔案系統、VMS、CVS）
大多數業務系統至少達部分持久，但交易中斷易導致資料損毀；持久系統透過「回滾」機制恢復至上一已知良好狀態。
J2EE 三大持久化技術
| 技術 | 特點 |
|---|
| 實體 Bean | 容器管資料完整性/資源/併發，開發者專注業務邏輯。BMP 寫持久化代碼容器定時機；CMP 容器生成代碼並管邏輯 |
| JDBC + Session Bean | 簡便 EJB 開發、跨平台部署、無 EJB 資源開銷。開發者寫持久化代碼與邏輯，自控何時持久化/載入 |
| Java Data Objects (JDO) | 最新機制，面向物件持久化，操作 POJO 載入/儲存持久資料 |
實體 Bean 優勢
- 標準化：廠商無關介面，最佳實踐、人才易得
- 容器管理服務：安全、交易、連線池、資源管理全托管
- 透明持久化：CMP 全自動；BMP 寫邏輯但容器管完整性/併發
- 交易支援：CMP 宣告式粗粒度控制；BMP 程式化細粒度控制，容器統管提交/回滾
- 元件化設計：部署描述符配置，零代碼修改跨伺服器部署
實體 Bean 痛點
- 設計複雜：幾乎必經 Session Bean 存取（雙 Bean 交易），容器黑盒行為不可預測，需大量場景測試
- 構建週期長：迭代週期比同級方案長 2-3 倍
- 回應時間：受限 Bean 顆粒度，大實體查詢慢，拆小則架構更複雜
- 資源霸佔：佔用大量伺服器資源，大實體併發請求回應極慢
Session Bean + JDBC 運作機制
Session Bean 透過資源管理器連線工廠存取資料：
- JNDI 查詢
javax.sql.DataSource
- 取得
java.sql.Connection
- 純 JDBC 代碼：查詢、更新、預存程序、ResultSet 導航、交易提交/回滾
Session Bean + JDBC 四大優勢
- 設計簡單：架構層面遠簡於實體 Bean
- 細粒度控制：完全掌控快取、持久化、併發、同步（CMP 無控制權，BMP 僅定義「做什麼」不定「何時/何況做」）
- 成熟穩定：JDBC 歷史 7+ 年（寫作時），可靠性與最佳實踐為寶貴資產
- 極致速度：開發者完全控制資料存取，可針對特定任務優化，直接操作產生極快回應
三大缺點
- 實作複雜：架構簡單但代碼常複雜——管理連線、確保完整性、處理交易語義、構建快取機制
- 非固有交易性：實體 Bean 本質交易元件；Session Bean 需開發者在代碼中硬編碼交易語義，確保業務規則/流控/交易完整性容錯
- 持久化非自動/不保證：實體 Bean 容器管持久化；Session Bean 開發者自負責資料落地安全存儲
實戰選型決策指南
| 決策維度 | 選 Session Bean + JDBC | 選實體 Bean |
|---|
| 讀寫模式 | 頻繁讀、極少寫 | 頻繁更新、高併發寫入 |
| 交易控制 | 需最大控制粒度 | CMP 宣告式最容易；BMP 次之 |
| 上市時程 | BMP/Session Bean 視專案而定 | CMP 最快（宣告類型/名稱/部署設定，工具生成其餘） |
| 資源使用 | 極輕量 | 資源密集型，大實體併發慎用 |
結語
雖趨勢偏好「原始 JDBC + 純無狀態 Session Bean」，但兩方案各有所長。關鍵在於：讀寫模式、交易控制需求、上市時程、資源預算四大維度權衡。下集將引入 JDO，三國演義終極對決——敬請期待！
