为什么hibernate强制在session.get方法中进行序列化

我看到hibernate的session.get（）和load（）方法只接受Serializable对象。

根据我对hibernate的理解，它将生成一个SQL语句并将其发送给DBMS。 它永远不需要通过网络发送java对象。

为什么hibernate强制对我们进行序列化？

Answer 1

首先，Hibernate在某些签名中使用Serializable这一事实并不意味着Hibernate 将序列化任何东西，它只是意味着如果需要，参数是可序列化的。

然后，我找不到绝对的参考，但我认为最强的论点是：

• 实体ID用作缓存的密钥（第一级，第二级），并且可以通过网络发送

一些较弱的参数（或根本不参数）：

• Session本身可以被潜在地序列化（例如存储在HttpSession ）
• Hibernate需要entityId的超类型（包括复合PK）

考虑到所有这些，我认为强制API的用户通过Serializable entityId ，这允许不关闭任何门并避免任何后期限制（oops，你不能激活二级缓存，因为这个pk不是Serializable ）。 这是IMO比使用Object更好的设计决策。 说实话，我没有看到任何烦恼。

Answer 2

这不是真的。 来自Javadoc ，相关方法的签名是：

 public Object get(Class clazz, Serializable id) ... public Object load(Class theClass, Serializable id) ... 

（为简洁起见，省略了不相关的部分和其他重载版本）。

因此，要加载的实体可以是任何类，只有它的标识符需要可序列化。

根据来自Java Persistence with Hibernate的引用，实体确实不是可序列化的。 13.3.2：

持久化实例以反汇编forms存储在二级缓存中。 将反汇编视为一个类似于序列化的过程（但算法比Java序列化要快得多）。

所以我猜测标识符（在查询缓存中）也没有序列化。 我找不到任何解释为什么id被声明为Serializable ，并且缺乏这个，我只能猜测。 API需要一个id参数的类型，它应该是至少常用的标识符类型Number和String的常见超类型，除了Object ， Serializable是唯一的选择。

Answer 3

我认为这是因为对缓存的支持。 当使用持久高速缓存或通过网络分发对象的任何高速缓存时，您需要有一种方法来确保对象可以以通用格式传输，在本例中是Java序列化。

Answer 4

坦率地说，我没有看到任何其他方式。 如果您不是定义表结构并生成插入语句以容纳对象，那么生成的SQL语句本身就是一个字符串，它会将另一个文本字符串（您的序列化数据）插入到表的字段中。 无论你在数据库中插入什么都必须是一个字符串，在这种情况下，它不能是一个具有语言相关方法的对象，除非你明确设计一个表来存储这样的数据。