幾個月前項目中用過hibernate。但是突擊式的學習過程。現在回想起來，還真是沒能留下什么痕跡。
今天開始，我將會在空閑時間寫下對Hibernate的一些認識。就當是一個 "認知" 的過程
Web應用框架(Jakarta Struts 對 WebWork)，GUI組件框架（Swing 對 SWT），或模版工具（JSP 對
Velocity）。每一種相互競爭的解決方案都有其優缺點，但它們至少都共享了相同的范圍與總體的方法。
不幸的是，這還不是持續性技術的情形，對持續性技術相同的問題有許多不同的混亂的解決方案。
前面這段話，意味深長。這是對"持續性技術"現狀的一個概括。
本著這種現狀去學習和研究"持續性技術"，把現今熟悉的"持續性技術"進行對比式的學習。尋求框架
的處理思路。分析他們的優點，缺點...
先思考幾個問題
1）數據持久到底有那些成熟的方式？
■ 直接使用SQL和JDBC進行工作 也可以結合DAO模式
■ 序列化持續性機制 他提供了將對象圖（應用狀態）寫到字節流中的能力，然后它可能被持續化到文件或數據庫中。
他也被Java的遠程方法調用（RMI）使用來為復雜對象傳遞值語義。他的另一種用法是在機器集群中跨節點復制應
用狀態。
■ EJB實體Bean
■ JDO
■ ORM 對象-關系映射：中間的短線強調了當這兩個領域相碰撞時出現的不匹配問題
■ XML持續層 XML持續層是序列化模式的變種。
■ 存儲過程
2）ORM解決方案有那些組成部分？
■ 在持續類的對象上執行基本的CRUD操作的一組API。
■ 用于指定查詢的一種語言或一組API，這些查詢會引用類和類屬性。
■ 用于指定映射元數據的工具。
■ 實現ORM的一項技術，用來與事務對象交互以完成臟檢查、懶關聯存取和其它優化功能。
3）實現ORM的有那些不同的方式？
■ 純關系
■ 輕量對象映射
■ 中等對象映射
■ 完全對象映射
4）相關的ORM有那些問題？
■ 持續類像什么？它們是細粒度的JavaBean嗎？或者它們是一些類似于EJB的組件模型的實例嗎？持續性工具有多么
透明？我們需要為業務領域的類采用一種編程模型或一些規范嗎？
■ 映射元數據是如何定義的？因為對象-關系轉換完全由元數據控制，這些元數據的格式和定義是重要的核心問題。
ORM工具應該提供一個圖形化處理元數據的GUI嗎？或者有定義元數據的更好的方法嗎？
■ 我們應該映射類的繼承層次嗎？這有幾種標準策略。多態關聯、抽象類和接口怎么映射呢？
■ 對象同一性和相等性如何關聯到數據庫同一性（主鍵）？我們如何將特定類的實例映射到特定表的行。
■ 在運行時持續性邏輯如何與業務域對象交互？這是一個普通的編程問題，有許多的解決方案包括源代碼生成、運行時
反射、運行時字節碼生成和編譯時字節碼增強。這個問題的解決方案可能影響到你的構建過程（但寧可如此，你也不
愿受到其它像用戶那樣的影響）
■ 持續性對象的生命周期是什么樣的？有些對象的生命周期依賴于其它關聯對象的生命周期嗎？
我們如何將一個對象的生命周期轉化為數據庫行的生命周期？
■ 為排序、檢索和合計提供了什么樣的工具？應用可以在內存中處理其中的一些事情。但為了有效地使用關系技術有時
需要通過數據庫完成這些工作
■ 如何有效地取出關聯數據？對關系數據的有效訪問通常通過表連接實現。面向對象的應用通常通過導航對象圖訪問數
據可能的話，兩種數據訪問模式應該避免n+1次選擇的問題，以及它的補充笛卡爾積的問題（在一次查詢中取出過多的
數據)
5）所有數據訪問技術都不得不面對的問題有那些？
■ 事務和并發性
■ 緩存管理（和并發性）