在休眠映射中使用包装器整数类或 int 原语答案

【问题标题】：Using wrapper Integer class or int primitive in hibernate mapping在休眠映射中使用包装器整数类或 int 原语
【发布时间】：2011-09-21 21:19:37
【问题描述】：

在我工作的公司中，我们主要讨论是否应该更好地为基元（java.lang.Integer、java.lang.Long）使用包装类，还是直接在在 Hibernate 中将实体映射到表的 POJO。

我们的想法是我们希望这些值在数据库中不为空。

支持使用原语的论据：

将这些值作为 int 处理意味着它们永远不能为空，在这样就不可能无意中获得空引用在场上。
int=32/64 位内存。整数 = 16 字节内存而且速度也较慢

支持使用包装对象的论据：

我们可以在数据库级别添加一个约束来始终防止 null 到达那里的价值
我们最终可能会得到误导性数据，我们可以每当用户没有时，数据库中有 0 而不是空值设置一个值和错误的数据是一个棘手的问题。
对象比基元具有更强的表现力。我们有空值，还有整数值，因此我们可以使用注释更轻松地验证它们示例 (javax.validation.constraints.NotNull)。

【问题讨论】：

您可以在不使用 JSR303 的情况下使用 hibernate 完成所有这些工作。虽然 JSR303 非常棒且向前迈进了一步，但 JSR303 有局限性，但 hibernate 可以解决这个问题。如果您使用 Wrappers，您将遇到很多问题并且当你有这么多 getIntValue 和 Parse 等语句时，代码最后会看起来很脏。不要使用包装器。

标签： java hibernate pojo primitive-types

【解决方案1】：

使用包装器，让您的生活变得简单。

您的数据模型应该规定这一点。无论如何，您应该在数据库中强制执行可空性。

如果它们在数据库中可以为空，则使用包装器。如果它们不可为空，并且您使用了包装器，那么如果您尝试将空值插入数据库，则会出现异常。

如果您的数据模型没有规定，那么请遵循约定，始终使用包装器。这样人们就不必思考或决定值 0 意味着 null。

我还会质疑您的断言，即它的性能会降低。你测量过这个吗？我的意思是真的测量过吗？当您与数据库交谈时，除了 16 位和 32 位之间的区别之外，还有更多的考虑因素。

只需使用简单、一致的解决方案即可。在任何地方都使用包装器，除非有人给你一个非常很好的理由（具有准确的测量统计数据）否则。

【讨论】：

+1 表示“无论如何都应该在数据库中强制为空性”，但我会说包装器使复杂而不简单。

【解决方案2】：

觉得应该提一下：

Hibernate 建议（第 4.1.2 节）在持久类中使用非原始属性实际上是指（如标题所示）标识符属性：

4.1.2。提供标识符属性

Cat 有一个名为 id 的属性。此属性映射到数据库表的主键列。该属性可能被称为任何东西，它的类型可能是任何原始类型、任何原始“包装器”类型、java.lang.String 或 java.util.Date。

...

我们建议您在持久类上声明一致命名的标识符属性，并使用可空（即非原始）类型。

尽管如此，原语的优势并不强：

在属性中具有不一致的非空值比 NullPointerException 更糟糕，因为潜伏的错误更难跟踪：从编写代码到检测到问题需要更多的时间，并且它可能会以完全不同的方式显示代码上下文而不是其源代码。
关于性能：在测试代码之前 - 这通常是一个过早的考虑。安全第一。

【讨论】：

这仍然是 Hibernate 5.1 的建议，但现在在“2.5.5。提供标识符属性”部分中

【解决方案3】：

Hibernate documentation（只是我碰巧找到的第一个版本）声明：

该属性可能被称为任何东西，其类型可能是任何原始类型、任何原始“包装器”类型、java.lang.String 或 java.util.Date。

...

我们建议您在持久类上声明一致命名的标识符属性，并使用可空（即非原始）类型。

所以“专家的声音”建议使用Integer/Long...但没有描述为什么会出现这种情况。

我想知道是否可以在没有标识符（即属性值为null）的情况下创建尚未持久化的对象，从而将其与持久化实体区分开来。

【讨论】：