是否有一個示例為什么應該在NHibernate中覆蓋Equals / GetHashCode？

Question

我發現很多帖子都解釋說應該總是在NHibernate實體類上重寫Equals / GetHashCode。 如果我不使用套裝，這真的有必要嗎？

我根本找不到一個示例，其中顯示缺少Equals / GetHashCode會導致意外和錯誤的行為。 沒有它們，一切似乎都很完美。 這是非常奇怪的，每個人都說這是必要的，但沒有人能提供一個樣本，說明為什么需要這樣做。

Answer 1

有一個問題上所以最近關於NHibernate的做選擇N + 1即使fetch指定。 問題是缺少Equals / GetHashCode實現。

答案鏈接到另一個類似的問題 。

這是關於Equals / GetHashCode覆蓋背后推理的另一個問題 。

Nhibernate n + 1與三元關系。 想要三元組中的中間實體
盡管有HQL提取，但Nhibernate生成代理
NHibernate：重寫Equals和GetHashCode的原因
為什么Equals和GetHashCode對NHibernate如此重要
為什么在重寫Equals方法時重寫GetHashCode很重要？

---

編輯

您無需一直覆蓋它們。 如果您使用復合鍵，具有分離實體的多個會話或無狀態會話，則可能是必要的。

如果您只使用單個會話，NHibernate會使用身份映射將實體存儲到第一級緩存。 在這種情況下，實體比較是通過比較ID來完成的。

在上述情況下（分離實體，無狀態會話），NHibernate比較實際實體，而不是它們的ID。 默認情況下， Object.Equals確實引用相等性。 因此，如果兩個對象指向完全相同的實例，則它們是相等的。 您可能有兩個具有相同標識的實例，但Object.Equals將為它們返回false 。 這與Entity 定義形成對比：

不是由其屬性定義的對象，而是由連續性線程及其標識定義的對象。

JBoss Hibernate wiki對Equals和HashCode有很好的解釋 ，只有很少的代碼示例。

Answer 2

事實上，只有極少數情況會導致副作用。 但如果你得到它們，它們就會非常微妙。 除了復合主鍵和字典鍵之外，它們總是需要正確的Equals / GetHashCode實現。

NH關心在內存中只實例化一次實體，因此默認參考比較應該有效... 如果沒有延遲加載 。

如果不覆蓋Equals，則在處理代理時會遇到問題。 總有兩個實例：代理和真實實體 。 它們都代表同一個實體。 只有使用正確實現的Equals方法，才會將其視為相同。