为什么hibernate强制在session.get方法中进行序列化 [英] why hibernate forcing serialization in session.get method

问题描述

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

I see that hibernate's session.get() and load() methods is accepting only Serializable objects.

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

As per my understanding of hibernate, it will generate an SQL statement and send it to DBMS. It will never need to send a java object over network.

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

Why hibernate is forcing serialization on us?

推荐答案

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

First of all, the fact that Hibernate uses Serializable in some signature doesn't mean that Hibernate will serialize anything, it just means that parameters are serializable if the need arises.

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

Then, I couldn't find an absolute reference but I think that the strongest argument is:

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

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

Some weaker arguments (or not argument at all):

• 会话本身可以被序列化（例如存储在 HttpSession ）


• Hibernate需要超级类型 entityId （包括复合PK）

• The Session itself can be potentially serialized (e.g. to be stored in the HttpSession)
• Hibernate needs a super type for entityId (including composite PK)

鉴于这一切，我很瘦k强制API的用户传递 Serializable entityId 是有意义的，这样就不会关闭任何门并避免任何后来的限制（哎呀，你不能激活二级缓存，因为此pk不是 Serializable ）。这是IMO比使用 Object 更好的设计决策。说实话，我没有看到任何烦恼。

Given all this, I think it makes sense to enforce users of the API to pass a Serializable entityId, this allows to not close any door and to avoid any later limitation (oops, you can't activate second level caching because this pk is not Serializable). This is IMO a much better design decision than using Object. And to be honest, I do not see any annoyance with that.

这篇关于为什么hibernate强制在session.get方法中进行序列化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！