?

使用 hibernate 快一年了，一直使用得比較膚淺，甚至沒有正式使用過對象關系。近段時間想深入研究一下，以便在項目中推廣，減少不必要的對象維護和編程。問題不期而遇，在多對多關系中，出現了遞規加載的現象，例如：用戶和角色的關系，一個用戶可能有多個角色，一個角色中包含多個用戶。我是通過帶有連接表的多對多關系實現的，用戶和角色對象中都維持了一個 Set 對象，用以延遲加載關系。但是，在我延遲加載用戶擁有的角色時，被加載的角色又加載它所包含的用戶，被加載的用戶又加載所擁有的角色，這樣遞規加載下去，由于 session 的關閉會拋出異常導致程序中止。開始百思不得其解，在仔細查看拋出的異常堆棧時，終于發現了問題所在。習慣！錯誤的習慣。我們所使用的持續層對象會繼承一個基礎類，該類“實現”了 hashCode 和 equals 方法，代碼如下：

hibernate 將用戶所擁有的角色對象放進 Set 中，實際 Set 會調用 hashCode 和 equals 來判斷兩個對象是否相等，這樣問題就來了， HashCodeBuilder.reflectionHashCode(this) 方法使用反射調用角色對象的 getUsers() 方法， hibernate 又加載角色所包含的用戶，能沒有問題嗎？繼而我們得反思一下持續層對象有沒有通用的 hashCode 和 equals 方法。

?????? 參考《深入淺出 Hibernate 》對 hashCode 和 equals 方法的處理有兩大種：

1、? 不覆蓋

問題：實體對象的跨 session 識別問題，根本在于 hashCode 默認調用 System.identityHashCode() 方法。

2、? 覆蓋

????????? 使用對象 pk

問題：新增對象時，沒有 pk ，那么所有的對象都相等了，也就是只能加入的一條。

????????? 值比對（對實體對象的所有屬性值進行比對，可以使用 Commonclipse 自動生成）

問題：過于嚴格。

????????? 業務關鍵信息判定

是值比對的一個子集，只做業務關鍵屬性的比對。

個人覺得業務關鍵信息判定的方法比較合理，使用 Commonclipse 自動生成值比對，注意兩點：

1、? 去掉實體關聯集合屬性的比對，不然又會出現我上述的“遞規加載”現象。

2、? 自動生成的 hashCode 方法去掉 appendSuper(super.hashCode()) ，自動生成的 equals 方法去掉 appendSuper(super.equals(object)) ，不然你的對象比較和加入 collection 都有問題的，《深入淺出 Hibernate 》書中沒有強調。