痛點：Entity Bean 讀取大量唯讀資料的三大代價
- N+1 問題：Finder 1 次 + 每個 Entity Bean `ejbLoad` N 次 = N+1 次 DB 往返。
- 遠端呼叫爆炸：每個 Bean 透過 Remote Interface 獲取資料，網路開銷巨大。
- 簡單 Join 變重構：多表關聯需實例化大量 Bean、處理關係維護，擴展性極差。
解決方案：Session Facade + JDBC + CachedRowSet
- 在 Session Bean 中直接用 JDBC 執行 SQL 查詢。
- 將 `ResultSet` 複製到 `CachedRowSet`（離線、可序列化）。
- 直接將 `RowSet` 傳回客戶端，對應表格行列，無需轉換為 Value Object。
RowSet 優勢
- 統一查詢介面，支援離線操作。
- 單次 DB 往返取回所有資料，無事務過載。
- 客戶端直接操作欄位（`getString("col")`），無需中間 DTO 層。
代價與限制
| 優點 | 缺點 |
|---|
| 查詢效能極佳 | 業務邏輯與持久邏輯緊耦合（SQL 散落業務層） |
| 減少網路往返 | 非 OO，編譯期無法檢查 SQL |
| 簡化代碼層次 | 維護性較差，易產生 Bug |
關鍵原則：讀寫分離策略
唯讀列表查詢 → JDBC + RowSet
業務更新/驗證/關聯維護 → Entity Bean
- RowSet 雖支援更新，**嚴禁**在應用中用於更新操作。
- 更新涉及業務規則、驗證、關聯級聯，必須由封裝規則的 Entity Bean 執行。
- 此模式與 Value Object、Generic Attribute Access 不相容，專為「大量唯讀顯示」優化。
適用場景判斷
- 報表、清單、下拉選項等**唯讀、大量、頻繁**查詢。
- 客戶端僅需表格化顯示，無複雜業務互動。
