| 維度 | Hibernate (全自動 ORM) | iBATIS (SQL 映射) |
|---|---|---|
| 學習曲線 | 陡峭，概念多 (Session、Proxy、Cache、HQL、映射細節) | 平緩，專注 SQL 與映射，易上手 |
| SQL 控制權 | 自動生成，難調優；可用 Native SQL 但破壞可移植性 | 完全掌控，DBA 可直接調優 SQL |
| 物件關聯 | 豐富 (一對多、多對多、繼承、元件映射) | 手動映射，靈活但需自行處理 |
| 開發效率 | 工具生成 Entity/Mapping，初期極快 | 需手寫 SQL/Mapping，初期較慢 |
| 維護性 | 模型變更波及面大，升級風險高 | SQL 與程式碼分離，修改局部化 |
| 適用場景 | 資料庫設計規範、物件模型豐富、團隊 ORM 經驗足 | 既有資料庫/髒資料、複雜報表/統計查詢、需精準 SQL 控制 |
| 專案特徵 | 推薦選擇 | 理由 |
|---|---|---|
| 新專案、資料庫可重設計、域模型豐富 | Hibernate | 發揮 ORM 全自動優勢，開發效率最高 |
| 既有資料庫、結構不規範、大量複雜 SQL | iBATIS | SQL 完全掌控，避開 ORM 阻抗失配 |
| 團隊無 ORM 經驗、時程緊 | iBATIS | 學習成本低，風險可控 |
| 需支援多資料庫產品 | Hibernate | 方言機制自動處理差異 |
| 高併發、極致效能調優需求 | iBATIS | SQL 層面精準控制，無 Proxy 開銷 |
採用 iBATIS DataAccess 作為 DAO 框架，可在同一專案中：
這樣既享受 ORM 便利，又保留 SQL 完全控制權，風險最低、架構最合理。
沒有最好的框架，只有最適合當下專案情境的選擇。iBATIS 以「小巧、靈活、SQL 掌控」見長，適合複雜既有系統；Hibernate 以「全自動、豐富物件圖、工具完善」見長，適合新建綠田專案。理解雙方設計哲學，才能做出理性決策。
