與生成的ID

實現對實體equals（）方法時，如果我有一個表列A，B，C，d
一個什麼是最好的做法：組合必須是唯一的（這是實際的商業意義定義的身份列）
d：一些列與生成的ID

現在，如果我要在此基礎上表中創建的業務對象（如JAVA）哪一個可以更好地實現equals（）方法：

基於A
定義平等基礎上B和C

定義平等或者，它不會真的不管我選擇哪兩個。

來源

2010-12-01 willy wonka

肯定是B和C，因爲您希望equals()合同即使在實體持續之前也有效。你說你自己：

這些都是實際在商業意義

定義的身份。如果是這樣的話列，然後就是邏輯equals()應該使用。數據庫密鑰是數據庫的關注點，應該與業務層無關。

並且不要忘記在hashcode()中也使用相同的屬性。

來源

2010-12-01 10:20:38

爲什麼在`equals（）`方法中排除`A`？ – 2010-12-01 10:22:57

因爲從業務角度來看，具有相同屬性B和C的持久實體和非持久實體是相等的。業務角度不應該關注像DB ID這樣的實現細節，這隻與模型相關。 – 2010-12-01 10:25:13

謝謝。我認爲我在倒退（首先實施，第二個業務意識）。你的回答讓我意識到這一點。謝謝。 – 2010-12-01 10:38:52

如果（B，C）是唯一對，則不需要自動生成的ID。對於表格，A相當於（B，C）（一對一關係）。

你可能想要或需要額外的密鑰，但我同意seanizer，使用（B，C）的等於和因爲A是多餘的（並且在對象被持久化之前和null），不要使用等於和散列碼）

來源

2010-12-01 10:29:14

我同意@SPFloyd。但我想添加更多。

有些情況下，實體沒有獨特的業務屬性。例如，一個實體可能只有A（PK）和B（商業物業），但許多實體具有相同的B值。

在這種情況下，很難創建equals()和hashcode()。您當然不希望將它們基於A，因爲您將無法將持久對象與尚未持久保存的對象進行比較。而且你不能僅僅依靠B，因爲那麼許多不同唯一實體的對象看起來是相同的。

我在這些情況下做的是有Date created = new Date();屬性。創建實體時，會自動獲取創建的時間戳。在我的equals()和hashcode()中，我包括B和created。這並不完美，因爲兩個對象可能同時創建的機會很小（特別是在集羣解決方案中），但這是一個開始。如果必須，請添加不是數據庫PK的UID或其他生成的業務屬性。

來源

2010-12-03 13:31:36 Tauren

與生成的ID

回答

相關問題