2009-08-02 27 views
0

在Java持久與Hibernate,加文認爲,我們用平等比較的業務重點。商業密鑰不僅可以涉及多個領域的比較,而且也不能保證「完美」的商業密鑰的語義將來不會改變。我們生活在非理想世界,商業需求和法律變化非常頻繁。在這種情況下,我們將留下存儲在多個業務密鑰語義中的數據庫中的數據。我想將問題分解成兩部分:Hibernate對象的身份

  1. 當我們嚴格處理持久或分離的對象時。
  2. 當我們處理瞬時對象。

  3. 我還沒有看到在使用了平等和hashCode代理鍵,如果我們處理的持續性和分離對象的任何缺點。如果兩個持久對象具有相同的主鍵,則它們是相等的。這是錯誤的假設?

  4. 當我們處理瞬態對象時,我們可以使用業務鍵語義來比較對象,並且如果嘗試使用相同的業務關鍵字持續兩個臨時對象但餘數屬性中的值不同,則可以使用合併策略。

在閱讀繁重的應用程序中,大部分事務都被讀取/更新,這種策略應該會產生更好的性能。

+0

什麼是「商業鑰匙」? – 2009-08-02 22:44:50

+1

商業密鑰唯一標識對象 - 該密鑰不應來自已經解釋過的數據庫。可以是實體中的UUID或組合或字段。 – JamesC 2009-08-03 11:19:57

回答

1

與對象的身份和Hibernate的問題是做短暫的對象:是主鍵創建時?如果答案是在寫入數據庫時​​(使用數據庫控制的主鍵生成(例如Oracle序列)),則存在潛在的問題。

如果使用主鍵作爲平等檢查的基礎,並且它是散列碼生成的一部分,那麼您將破壞散列碼合約,因爲在生成主鍵之前和之後對象不會相同。

如果可以,只要使用,您可以設置在創建對象的時候(如UUID)生成的主鍵。這可確保您的哈希碼和相等性檢查保持一致。

1

我曾經感到苦惱發現每個類別的最佳業務鍵和最終會在情況下使用UUID那裏實在是沒有什麼獨特之處在於可以永遠不會改變。但是現在,我使用數據庫代理鍵,並避免了必須依賴相等性來實現瞬態對象的情況。看起來更簡單,不易出錯,速度更快。它可能取決於應用程序的類型,但對於典型的CRUD應用程序,該對象通常在進入數據庫之前必須在集合中進行處理。