java - 使用“持续时间”、“期间”或“年月”作为类字段类型是否合适？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 3 年前。

Improve this question

当类字段定义为 Duration 时，我找到了一些代码, Period或YearMonth而不是某些日期、时间或日期时间类型，甚至是持续时间情况下的基元。

那些java.time类似乎是更多的实用程序，可以帮助我们在某个字段上进行转换、转换和/或操作，但存储/检索它可能是通过更原始/低级的可用类型来完成的。

在存储级别上，我可以看到类似 PT60S 的持续时间这是时间间隔的标准，但可能并未被所有语言或数据库广泛采用。在数据交换或迁移的情况下，这可能会变得令人头痛

在像 mongo 这样的 NoSQL DB 中，该值存储为 String但在 SQL DB 中，必须定义一种原始类型并准备迁移。作为一个字符串，存储某人想要的任何东西都是有风险的。

存储此类信息以避免将来出现错误和麻烦的最佳方式是什么。

可能的时间间隔方法示例:

class TaskScheduler {         class TaskScheduler {
  String name;                  String name;
  Duration timeout;             Integer timeoutInSeconds;
  TaskStatus status;            TaskStatus status;
}                             }

Answer 1

不确定Period，但Duration和YearMonth都是XML Schema简单类型。我还没有看到它们在该上下文之外使用。

In my personal opinion those java.time classes are utilities that helps us to transform, convert and/or operate over a certain field but the storing/retrieving it might be done by a more primitive/low-level available type.

有可能。或者也许理想的是一个类可以表示原始值而不丢失任何信息，并且还可以在请求时将自己呈现为原始类型？

Am I being too resistant to adopt latest APIs and loosing the advantage they are bringing to the table or is there actually a valid concern on this approach?

根据您提供的信息，我无法确定代码是否应该使用这些类。当涉及重写别人的代码时，通常的规则适用。准备好用事实来捍卫你的决定，并确保你不会落入他们试图避免的任何陷阱。