数据访问对象原始类型与对象类型？答案

【问题标题】：Data Access Object Primitive Type vs Object type?数据访问对象原始类型与对象类型？
【发布时间】：2011-12-08 01:31:22
【问题描述】：

希望对最佳方式提出意见。

如您所见，int 不能为空。 Integer 的对象可以在哪里。

问题：具有数字列的数据库值可以为空或可以包含数字。当数据库传递空值时，我们会收到异常声明 “原始值不能为空”

但是当我们使用 Integer 类时，我们正在创建该对象（当然它比原始类型 int 更大/更大）

所以这给我带来了几个选择。

还有其他建议吗？

【问题讨论】：

如果您的数据模型包含一个由整数原语表示的值，那么您应该设计您的数据库以尊重该设计。如果你不这样做，你只会给自己制造不必要的问题。向数据库添加一个列约束，强制该特定列不是 NULL。

【解决方案1】：

如果您查询数据库（5000 op/sec），我认为您不必担心整数 int 转换性能（100000000 opsec）。勇敢地使用盒装类型。

【讨论】：

【解决方案2】：

使用Hibernate（或类似的ORM），让框架直接处理数据库。然后，您可以按照自己的喜好对其进行编程，而不必处理转换。

重新发明轮子很少能像一开始就使用别人的轮子那样奏效，尤其是当成千上万的人已经在使用同一个轮子时。

【讨论】：

确实，但无论哪种方式，原始类型都不能为空。因此，如果您的数据访问对象使用原始类型。如果你的数据库没有它的值，那么它会抛出一个异常
那么你不能使用原始类型（如果你需要它为空），可以吗？如果您需要可空原语，请使用支持它的语言，或使用该原语的可空版本（在本例中为整数）。
啊，但这就是问题所在......我们应该使用原始类型并将所有数据库值设置为某种默认值，还是在数据访问上使用整数类型会更聪明对象（体积更大，占用更多空间）？
正确建模数据。如果 null 为 null，则使用 null。将已经解决的问题的解决方案组合在一起只会产生更多的问题。如果存储空值无效，则不要存储它们。如果是，则将它们存储为空。对象模型和数据库模型也是如此。在你能证明这是一个问题之前，不要担心大小。在其他问题显示更加重要之前，可维护性是第一大问题。
你说得很好。我想或多或少，我在考虑更大的图景，而不仅仅是简单的整数，而是随着软件变得越来越大。

【解决方案3】：

我的选择：

首先-如果可能并且在逻辑上可以在数据库中设置默认值（可能是具有所有值+默认值的参考表的 FK）。

第二 - 如果第一个是不可能的，我会毫无保留地使用 Integer 对象。我不认为你会有性能问题。代码将是干净的，但记录在“可以包含 null 并在处理此变量时检查 null”的变量中。

我总是会选择更易读和易于理解的东西，以保持软件的可维护性和灵活性。

【讨论】：

任何时候你使用一个整数（与一个整数相对），你需要假设它可能是空的，就像 any 对象引用一样。如果你不这样做，你只是在寻找错误。
但是如果设计中有不变量指出特定对象不能为空并且它应该始终包含一个有效对象，那么我就不会关心检查空值。如果它在运行时为空，则让它失败并返回 NPE。我们应该快速失败。但在他的情况下，NULL 是一个有效值。所以我让他检查 Null。
总的来说，我同意。但是，对于整数，具体来说，可以通过将任何不变的整数转换为整数来改进设计。如果有一种更简单、类型更安全的方式来表示让代码自己说话的约束，那就是更好的方式。
我也喜欢这个回应，我同意，但从长远来看，我正在检查许多原始类型的性能/空间。谢谢大家