我将尝试回答几个关键点：这是基于长期的Hibernate /持久性经验，包括几个主要应用程序。
实体类：实现可序列化吗？
密钥 需要实现Serializable。将要在HttpSession中存储的东西，或由RPC / Java
EE通过电线发送的东西，都需要实现Serializable。其他东西：不是很多。把时间花在重要的事情上。
构造函数：使用实体的所有必填字段创建构造函数吗？
用于应用程序逻辑的构造函数应仅具有几个关键的“外键”或“类型/种类”字段，这些字段在创建实体时始终是已知的。其余的应该通过调用setter方法来设置-
这就是它们的用途。
避免将太多字段放入构造函数中。构造函数应该很方便，并且要使对象基本清醒。名称，类型和/或父母通常都是有用的。
OTOH（如果今天（今天）应用规则要求客户提供地址，请将其留给设置者。那是“弱规则”的一个例子。也许下周，您想在进入“输入详细信息”屏幕之前创建“客户”对象吗？不要绊倒自己，留下未知，不完整或“部分输入”数据的可能性。
构造函数：另外，封装私有默认构造函数？
是的，但请使用“受保护的”而不是私有包。当必要的内部结构不可见时，子类化的东西是一个真正的痛苦。
字段/属性
从实例外部对hibernate使用“属性”字段访问。在实例内，直接使用字段。原因：允许标准反射（Hibernate最简单，最基本的方法）起作用。
至于应用程序“不可变”的字段-
Hibernate仍然需要能够加载它们。您可以尝试将这些方法设为“私有”，和/或在其上添加注释，以防止应用程序代码进行不必要的访问。
注意：编写equals（）函数时，请在’other’实例上使用getter作为值！否则，您将在代理实例上点击未初始化/空白的字段。
受保护的（hibernate）性能更好？
不太可能。
等于/哈希码？
这与在保存实体之前使用实体有关-这是一个棘手的问题。哈希/比较不变值？在大多数业务应用程序中，根本没有。
客户可以更改地址，更改其业务名称等，虽然不常见，但确实如此。当数据输入不正确时，还需要进行校正。
通常保持不变的几件事是育儿，也许还有类型/种类-通常，用户重新创建记录，而不是更改它们。但是这些并不能唯一地标识实体！
因此，总之，所谓的“不变”数据并不是真的。主键/ ID字段是出于精确目的而生成的，以提供这种保证的稳定性和不变性。
当A）如果在“不经常更改的字段”上进行比较/散列，或者B）在“不经常更改的字段”上进行比较/散列，则需要计划和考虑比较，散列和请求处理工作阶段的需求。未保存的数据”，如果您比较/哈希ID。
Equals / HashCode-如果没有唯一的业务密钥，请使用在初始化实体时创建的非临时UUID
是的，这是必要时的好策略。请注意，UUID不是免费的，但是从性能角度来看，它使集群变得复杂。
等于/哈希码-从不引用相关实体
“如果相关实体（例如父实体）需要成为业务密钥的一部分，则添加一个不可插入，不可更新的字段来存储父ID（与ManytoOneJoinColumn的名称相同）并在相等性检查中使用此ID ”
听起来像个好建议。
希望这可以帮助！
