@Transient 属性应该在 equals/hashCode/toString 中使用吗？

Question

我有 JPA 实体，其中一些属性用 @Transient 注释。

我应该在 equals/hashCode/toString 方法中使用这些属性吗？

我的第一个想法是不，但我不知道为什么。

• 尖端？
• 有想法吗？
• 解释？

Answer 1

toString() 的情况有所不同，您可以使用 toString() 执行任何您想要的操作，因此我将仅介绍 equals() （并且hashCode())。

首先，规则：如果您想将对象存储在 List、Map 或 Set 中，那么它是要求实现equals 和hashCode，以便它们遵守文档中指定的标准约定。

现在，如何实现equals()和hashCode()呢？一个“自然”的想法是使用映射为 Id 的属性作为 equals() 的一部分：

public class User {
    ...
    public boolean equals(Object other) {
        if (this==other) return true;
        if (id==null) return false;
        if ( !(other instanceof User) ) return false;
        final User that = (User) other;
        return this.id.equals( that.getId() );
    }
    public int hashCode() {
        return id==null ? System.identityHashCode(this) : id.hashCode();
  }
}

不幸的是，这个解决方案有一个主要问题：当使用生成的标识符时，直到实体变得持久时才会分配值，因此如果瞬态实体在被添加到Set之前保存后，其哈希码在 Set 中时会发生变化，这会破坏 Set 的约定。

因此，推荐的方法是使用属于业务密钥一部分的属性，即对于具有相同数据库标识的每个实例来说唯一的属性组合。例如，对于 User 类，这可能是用户名：

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();
  }
}

Hibernate 参考文档对此进行了如下总结：

“永远不要使用数据库标识符来实现平等；使用业务密钥，这是唯一的、通常不可变的属性的组合。如果将瞬态对象持久化，则数据库标识符将会更改。如果瞬态实例（通常与分离实例一起）保存在 Set 中，更改 hashcode 会破坏 Set 属性 的业务密钥约定。不必像数据库主键一样稳定，只要对象在同一个 Set 中就可以保证稳定性。” - 12.1.3。考虑对象身份

“建议您使用业务键相等来实现 equals() 和 hashCode()。业务键相等意味着 < code>equals() 方法仅比较构成业务键的属性，它是在现实世界中标识我们的实例的键（自然候选键）” - 4.3。实现 equals() 和 hashCode()

那么，回到最初的问题：

• 如果可能的话，使用业务密钥。 @Transient 属性很可能不是此类键的一部分。
• 如果不可能，请使用标识符属性，但确保在将实体添加到 List、Map、Set 之前获取分配的值。

另请参阅

• Equals 和 HashCode
• 不要让 Hibernate 窃取您的身份
• Hibernate 中的 equals 和 hashcode
• 理解 Java 中的 equals() 和 hashCode() (p. 396)持久化 Hibernate

Answer 2

据我所知，@Transient 和 Transient 的两种典型用法是将它们用于无法序列化/持久化的内容（例如远程资源） 句柄）或可以从其他属性重建的计算属性。

对于计算数据，在相等关系（equals/hashCode）中使用它们是没有意义的，因为它是多余的。该值是根据等式中已使用的其他值计算得出的。然而，在 toString 中打印它们仍然有意义（例如，使用基本价格和比率来计算实际价格）。

对于不可序列化/可持久化的数据，这取决于情况。我可以想象一个不可序列化的资源的句柄，但您仍然可以比较该句柄代表的资源名称。对于 toString 也是如此，也许打印句柄资源名称很有用。

这是我的 2 美分，但如果你解释一下 @Transient 的特殊用法，也许有人可以给出更好的建议。

Answer 3

异常可能来自于让它成为瞬态，同时您在处理它的地方提供了 writeObject() 和 readObject() 。