c# - 处理与服务定位器模式一起使用时 MongoDB 如何存储 DateTime

Question

我和我的同事在辩论中陷入僵局，非常感谢其他人的意见。

我们利用服务定位器模式和一个公共(public)接口(interface)来抽象我们所有的数据访问，这样我们就可以随着需求的变化轻松地在不同的数据源之间进行交换。我们的调用代码没有指示数据存储在何处或如何存储。它只是通过服务注册表提供的服务访问数据。

当我们在对象上有 DateTime 字段并将其存储到 MongoDB 数据源时，我们正在讨论的问题就出现了。

我注意到，当我们在 C# 中有一个带有 DateTime 的对象时，它显示为正确的时间。当我们使用 MongoVUE 登录我们的 MongoDB 服务器以检查对象时，它会显示正确的时间。但是当我们检索对象时，日期时间现在是 UTC。将内存中的日期时间与从 MongoDB 数据源检索到的对象中的日期时间进行比较时，这显然会产生问题。

我知道 Mongo 在内部将 DateTime 存储为 UTC 时间。我什至理解为什么当您调用它时它可能会返回 UTC。

辩论从这里开始。

有人认为这只是一个表面问题，只是显示日期时的问题。因此，我们应该简单地在接口(interface)层中调用 .ToLocalTime。我不同意并断言这会危险地破坏我们在实现服务定位器模式时创建的抽象层。它还提出了有关与这些日期时间交互的问题，因为它涉及触发其他事件。

我在其他地方读到的是，我们应该将时间存储为字符串，特别是 UTC 格式的某种标准。以这种方式，接口(interface)层不知道或不关心 DateTime 是如何存储的，我们的对象也不知道或不关心，因为每个数据源都会以相同的方式存储该字符串。

我已经成功地使用 ISO 1806 格式完成此操作，但我的同事认为这是一个“hacky”修复，使用 .toLocalTime 是处理这种情况的合适方法。

我对其他人对这个话题的看法很感兴趣。

预先感谢您的输入。

Answer 1

为什么不首先将 UTC 存储在数据库中？在大多数情况下，DateTime 应该存储为 UTC，因为它通常指的是一个时间点。这适用于任何在物理意义上指代时间的事物，以及任何假定时间是单调的、递增的和唯一的事物，但对于大多数本地时间而言，这些都不是真的。

有时候，使用本地时间确实有意义:假设一辆公共(public)汽车每天早上 9 点发车。这意味着两个连续事件之间相隔 24 小时。但是，如果时区有夏令时，则每年一次分别为 23 小时和 25 小时。

但是，如果您需要处理此类数据，简单的 DateTime 无法解决问题； DST 规则可以更改，时区可以更改等。在 C# 中，将应用的 DST 规则是当前有效的规则，即使日期是“历史”。因此，具有历史日期的日期算法可能会造成严重破坏。如果你真的需要处理这个问题，至少，你应该存储时间所在的哪个时区(不仅是偏移量，甚至只是一个 isLocal 标志) .

在数据库中存储可以二进制存储的文本信息对我来说似乎不是很优雅，在某些中间层更改值也不是。前者效率低下并且存在前面提到的本地时间的特殊性，后者只有第二个问题。

顺便说一句，要完成后者，您可以使用 [BsonDateTimeOptions(Kind=DateTimeKind.Local)] 装饰属性，这将为您进行转换，但会遇到同样的问题，当然。