在上篇系列中我簡要的談到了一下Hibernate的基本的實用方法，在這裏我覺得對於一個技術（不論是開源項目或是行業中的某種標準技術）我們的認知是可以分爲四個層次：
第一個層次是“知道，瞭解”，它的要求僅僅是我們聽說過這個技術，知道它是幹什麼的或是看過幾篇文章，可以跟人簡單的侃一侃；第二個層次是“會用”，就是能夠就這個技術熟練的寫出"hello world"，掌握了其基本的用法，能夠在實際項目中使用；第三個層次是“精通”，就是對於這個技術很熟練了，知道其內部原理和優化使用，能夠解決在實際項目中使用這種技術遇到的一些“靈異問題”，算是使用這個技術的大哪了；第四個層次是“融會貫通，創新”，即不但能熟練的使用這個技術，並且能理解這個技術的優勢或新異的本質，能夠將這個本質應用於其它的一些實現中，並不拘泥於這個技術中。由此可見，對於一個新技術的掌握，其層次是分的很開的，層次不同，當然其掌握就不一樣，所需要花的時間也不一樣，所以經常看有些書封面寫的多少小時完全掌握一個什麼技術，其實那都僅僅是個皮毛。
好了，言歸正轉，我們來談談Hibernate中的一些較深的內容。
先來看看實體映射，簡單的實體映射就不用太多說了，一個表對應一個pojo利用xxx.hbm.xml配置文件，這裏有一點要注意就是pojo的bean文件中setter或是getter方法要制定成public的，這要可以提供Hibernate的性能。對於pojo的某個屬性我們可以採用自定義的數據類型，即非基本數據類型，例如List，但其實這僅僅在於從數據庫表中讀出時可以自動專程List，而我們在寫入時還是數據庫表所支持的那些數據類型。對於數據庫表我們知道其還有複合主鍵的概念，Hibernate同樣支持。另外一個是對Blob，Clob這樣的大字段類型的映射，Hibernate和Oracle配合起來有些特殊，和Sql server2000則沒有。
以上是簡單的實體映射，像Hibernate這樣的ORM解決方案來說難點在於二維的關係型數據庫表和麪向對象結構（面向對象的特點有封裝，繼承，多態）的POJO的對應，簡單的映射是沒有反應出面向對象的特性的。 我們可以將一個表中的字段分別映射到多個 POJO中，這樣在設計的粒度上更加清晰，實際上也是實現了對於傳統關係型庫表的面向對象的領域劃分，在xxx.hbm.xml中使用結點component。 在Hibernate3中對於POJO的屬性提供了延遲加載，這樣可以有效地提高我們讀取部分表字段的性能。對於繼承關係的多個POJO，Hibernate也提供了3種映射方法：一是父類和各子類都對應一個表（這在我的一個實際項目中可以採用這種方式來解決數據庫表的union的問題，當然也可以用HQL查詢語言來解決），在做查詢時Hibernate會自動查詢所有父類和子類對應的表，這種方法不好的地方在於改動父類的屬性映射，各子類的映射文件也要改動；第二種方法是子類對應的表中只包含擴展的屬性字段，這樣的話xxx.hbm.xml只需要一個，在配置文件中利用joined-subclass結點來引入子類的控制屬性的映射；最後一種方法是隻要一個大表，將父類和各子類所以得屬性字段都包括進來，配置文件也是一個，需要用到discriminator節點來聲明子類辨別標示的字段，這也就是說在數據庫表中要多一個字段來做標示作用，另外用到subclass節點來配合discriminator節點。
以上是實體映射方面，下面我們來談談另一個比較麻煩的問題--數據關聯
所以我們要明白數據關聯不等同於聯合查詢（就是指select中的join)，我們在以前的面向sql語句的數據庫編程中是沒有數據關聯這個概念的，以前我們對於多表之間的一條sql語句的操作只限於select，但有了數據關聯，我們可以同時對多表進行增，刪，改。這都是由於現在是有了ORM的技術，纔有了數據關聯這個概念，因爲對象是很容易產生關聯的，想象我們以前如果要往兩個表中都插入一條記錄，我們要寫兩條sql語句，然後batch執行，現在我們只須對一個對象進行save，通過xxx.hbm.xml的配置Hibernate會自動往另一個表中插入一條數據，當然其底層實現上還是有兩條sql語句的，只不果我們在上層應用時不用寫出來。
說了這麼多，到底數據關聯具體是怎麼回事了？
數據關聯可以看成是兩個表之間的對應的某條或幾條數據之間的關聯（爲什麼是兩個表之間，而不是多個表之間了，應爲多個表之間的關聯到具體的都可以拆成兩兩關聯），那這些關聯可分爲一對一關聯，包括主鍵關聯，外鍵關聯；一對多關聯，包括單向一對多和雙向一對多（也就是一對多和多對一）；多對多關聯。
具體的配置和特性我們下篇blog在講。另外還有在下一篇還要談到Hibernate的一些高級特性和性能優化方面的問題，這也可以算成是第三個層次了，呵呵。
未完，待續........