在Hibernate中持久化Joda DateTime而不是Java Date

我的实体目前包含java Date属性。 我开始经常使用Joda Time进行日期操作和计算。 这意味着我不得不将我的日期转换为Joda DateTime对象并再次返回。

所以我想知道,有什么理由我不应该只更改我的实体来存储Joda DateTime对象而不是Java Date对象?

请注意,这些实体是通过Hibernate持久化的。 我找到了jodatime-hibernate项目,但我也在Joda邮件列表上读到它与较新版本的hibernate不兼容。 而且似乎维护得不是很好。

所以我想知道是否最好继续在Date和DateTime之间进行转换,或者是否明智地开始持久化DateTime对象。 我担心的是依赖于维护不善的图书馆。

编辑:请注意,我的目标之一是更好地存储时区信息。 仅存储日期似乎将日期保存在本地时区。 由于我的应用程序可以在全球范围内使用,我也需要知道时区。 Joda Time Hibernate似乎也在用户指南中解决了这个问题。

我认为使用Joda DateTime作为你的bean属性类型可能是一个好主意。 然后,您可以让Hibernate执行转换并将属性保存为本机数据库日期格式。

我个人使用了jodatime-hibernate,并没有遇到任何问题(我们使用的是Hibernate 3.2.5GA)。

如果您对jodatime-hibernate有疑虑,可以随时使用Hibernate的自定义类型映射机制 (我确信这都是jodatime-hibernate所做的)。

Joda Time Hibernate可以与最近的Hibernate版本一起使用 – 您可能需要稍微调整一下所有的依赖图(例如设置排除项)。 我还可以建议您查看我已发布到Sourceforge上的用户类型。 这为Joda Time提供了用户类型,旨在避免您提到的客户端偏移问题。 我欢迎您对该项目的任何反馈。 https://sourceforge.net/projects/usertype/files/

问候克里斯。

所以,总结一下:

java.util.Date

  • + Hibernate中的原生支持
  • – 糟糕的API

乔达时间

  • +更好的API
  • – 在Hibernate中缺乏原生支持

就个人而言,如果我可以通过仅使用第三方库(在这种情况下显然是Hibernate的用户类型)来保持域模型和“服务层”清洁,另一种方法是编写一些额外的代码来“手动”进行每次转换需要时间,我会去第三方图书馆。

日期不应使用高级抽象存储,例如字符串(“2009-08-07 07:43:19 ……”),也不应存储为Java对象。 从纪元开始,它们应该以毫秒为单位持续存在。 Joda时间和常规Java日期时间都可以为您提供自纪元以来毫秒的时间。 存储经过的毫秒数,并在从数据库读回时转换回对象。

保持重量级日期对象而不是长对象有点像使用浮点数来表示货币金额:它通常是巨大的代码味道。