在Hibernate / WebApp上下文中的对象相等

Question

如何处理由hibernate管理的Java对象的对象相等性？他们在《冬眠的行动》一书中说，人们应该更青睐商务钥匙而不是代理钥匙。
大多数时候，我没有业务密钥。想想映射到一个人的地址。地址保存在Set中并显示在Wicket
RefreshingView中（使用ReuseIfEquals策略）。

我可以使用代理ID或使用equals（）和hashCode（）函数中的所有字段。
问题在于这些字段在对象的生存期内会发生变化。因为用户输入了一些数据，或者由于在OSIV（在视图中打开会话）过滤器内调用了JPA
merge（），所以id发生了更改。

我对equals（）和hashCode（）协定的理解是，这些协定在对象的生存期内不应更改。

到目前为止我尝试过的是：

• 基于使用数据库ID（或id为null的super.hashCode（））的hashCode（）的equals（）。问题：新地址以空ID开头，但在附加到某人后会获得一个ID，此人在osiv过滤器中被merged（）（重新附加）。
• 首次调用hashCode（）时，延迟计算哈希码，并将该哈希码设为@Transitional。不起作用，因为merge（）返回一个新对象，并且哈希码不会被复制过来。

我需要的是我认为在对象创建期间分配的ID。我在这里有什么选择？我不想引入一些其他的持久属性。有没有一种方法可以明确地告诉JPA为对象分配ID？

问候

Answer 1

使用id实体的并不是一个好主意，因为临时实体还没有ID（并且您仍然希望临时实体可能等于持久性ID）。

使用所有属性（除了数据库标识符）也不是一个好主意，因为所有属性都不是标识的一部分。

因此，实现平等的首选（正确）方法是使用 业务密钥 ，如 Java Persistence with Hibernate中所述 ：

用业务密钥实现平等

要获得我们推荐的解决方案，您需要了解业务密钥的概念。业务密钥是属性或属性的某种组合，对于具有相同数据库标识的每个实例都是唯一的。本质上，如果您不使用代理主键，那么它就是您要使用的自然键。与自然主键不同，并非绝对要求业务键永不更改-
只要它很少更改，就足够了。

我们认为，基本上每个实体类都应该具有一些业务密钥，即使它包含了该类的所有属性（这对于某些不可变的类也是适当的）。业务密钥是用户认为唯一标识特定记录的东西，而代理密钥是应用程序和数据库使用的东西。

业务密钥相等性意味着equals（）方法仅比较构成业务密钥的属性。这是避免前面描述的所有问题的理想解决方案。唯一的缺点是，首先需要额外的思想来识别正确的业务密钥。无论如何，都需要这种努力。如果您的数据库必须通过约束检查确保数据完整性，则标识任何唯一键非常重要。

对于User类，username是一个很好的候选业务密钥。它永远不会为null，它具有数据库约束是唯一的，并且很少更改（如果有的话）：

    public class User {
        ...
        public boolean equals(Object other) {
            if (this==other) return true;
            if ( !(other instanceof User) ) return false;
            final User that = (User) other;
            return this.username.equals( that.getUsername() );
        }
        public int hashCode() {
            return username.hashCode();
        }
}

也许我错过了一些东西，但是对于地址，业务密钥通常由街道号，街道，城市，邮政编码，国家/地区组成。我认为没有任何问题。

以防万一，Equals And
HashCode是另一个有趣的读物。