在 Java 应用程序中将原语更改为盒装原语的后果

发布于 2024-10-16 17:24:55 字数 609 浏览 1 评论 0原文

我正在开发一个应用程序,其中给定项目的所有性能值都是基元。但是,现在向系统添加新数据时,这些值之一(收入)可能不可用。在这些情况下,我们只需将 Revenue 值存储/显示为 0.00 就可以了。

但是,我们现在还希望能够在以后添加这些缺失的数据(但不覆盖数据(如果存在))。在我看来,将 Revenue 从原始类型 double 更改为装箱原始 Double 并允许数据库中 Revenue 列为 NULL 是显而易见的,而不是添加标志来指示 Revenue 在将 0.00 添加到数据库时是否实际可用。

然而,应用程序中有多个地方调用 getRevenue(),并对值执行数学运算。显然,现在 getRevenue() 返回 null 的可能性可能会导致重大问题。正如我所提到的,我们非常乐意在不存在任何值的情况下将收入显示为 0.00。

因此,似乎一个明显的解决方案是更新 getRevenue() 方法以返回值,或者在值为 null 的情况下返回 0.00。并添加一个新方法 getRevenueDB(),它返回 Revenue 的真实值,包括 null。仅当访问要添加到数据库的值时才会调用此方法。

这看起来如何?它应该可以工作,而且速度很快。但这似乎是一个非常肮脏的解决方案,有更好的选择吗?

非常感谢所有评论!

I am working on an application in which all performance values for a given item are primitives. However, there is now the possibility that one of these values - Revenue - is not available when adding new data to the system. In these cases we are fine with simply storing/displaying the value for Revenue as 0.00

However, we now also want to be able to add this missing data at a later date (but not overwrite data if present). Rather than adding flags to indicate whether Revenue was actually available when 0.00 was added to the database, it seems obvious to me to change Revenue from the primitive type double to a boxed primitive Double, and allow NULLS for the Revenue column in the db.

There are various places in the application where getRevenue() is called however, and mathematic operations are performed upon the value. Obviously now having the potential for getRevenue() to return null could cause major problems. As I mentioned though, we are perfectly happy to present Revenue as having a value of 0.00 in the cases where there is no value present.

So, it seems like an obvious solution would be to update the getRevenue() method to return the value, or 0.00 in the case of the value being null. And to add a new method getRevenueDB() which returns the true value of Revenue, including null. This method would only be called when accessing the value to add to the db.

How does this seems as a solution? It shouold work, and is quick. But does this seem a horribly dirty solution, for which there is a better option available?

All comments are much appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

﹉夏雨初晴づ 2024-10-23 17:24:55

您实际上有两个客户端,一些需要查看 NULL,一些则明确不能查看 null。

如果确实将“不知道”转换为“零”具有商业意义,那么我认为拥有两个不同的访问器是有效的。

我可能会选择一个与 getXxxxDb() 不同的名称,例如 getXxxxxOrNull(),我的推理是可以想象,不仅是 Db 最终会关心它是否为空,

You effectively have two clients, some who need to see NULLs some who explicitly must not see nulls.

If it really is the case that it makes business sense to convert "Don't Know" to "Zero" then I think it's valid to have two different accessors.

I might choose a different name that getXxxxDb() for example getXxxxxOrNull(), my reasoning being that it's conceivable that it's not only the Db that will care eventually if it's null,

旧话新听 2024-10-23 17:24:55

将“无值”表示为 null 是正确的做法。

另一种实现是在每次调用 getRevenue() 后在必要的地方插入 null 检查,这也是可以的。取决于您是否希望在模型或服务层中增加额外的复杂性。

Representing "no value" as null is the correct thing to do.

The alternative implementation is to insert null checks after every call to getRevenue() where it is necessary, which is also ok. Depends whether you want your additional complexity in your model or service layer.

说谎友 2024-10-23 17:24:55

当您要存储空/缺失的 Revenue 时,将 Revenue 列保持为 not null 并将其存储为零怎么样?您甚至可以使用触发器或默认值在数据库级别执行此操作。

What about keeping the Revenue column as not null and storing it as a zero when you have an empty/missing Revenue to store? You may even be able to do this at the database level with a trigger or a default value.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文