web-services - 在整个交易过程中始终使用 "now"的值

Question

我正在寻找在整个交易过程中使用一致的当前日期和时间值的指南。

事务我松散地指的是应用程序服务方法，这些方法通常执行单个 SQL 事务，至少在我的应用程序中是这样。

环境语境

this question 的答案中描述了一种方法是将当前日期放在环境上下文中，例如DateTimeProvider , 并使用它而不是 DateTime.UtcNow到处。

然而，这种方法的目的只是使设计可单元测试，而我还想防止由于对 DateTime.UtcNow 进行不必要的多次查询而导致的错误。 ，其中一个例子是:

// In an entity constructor:
this.CreatedAt = DateTime.UtcNow;
this.ModifiedAt = DateTime.UtcNow;

这段代码创建了一个创建日期和修改日期略有不同的实体，而人们期望这些属性在创建实体后立即相等。

此外，环境上下文很难在 Web 应用程序中正确实现，因此我提出了另一种方法:

方法注入(inject) + DeterministicTimeProvider

DeterministicTimeProvider类被注册为“每个生命周期范围的实例”AKA“Web 应用程序中每个 HTTP 请求的实例”依赖项。

它被构造函数注入(inject)到应用程序服务中，并传递到实体的构造函数和方法中。

IDateTimeProvider.UtcNow使用方法而不是通常的 DateTime.UtcNow/DateTimeOffset.UtcNow到处获取当前日期和时间。

这是实现:

/// <summary>
/// Provides the current date and time.
/// The provided value is fixed when it is requested for the first time.
/// </summary>
public class DeterministicTimeProvider: IDateTimeProvider
{
    private readonly Lazy<DateTimeOffset> _lazyUtcNow =
        new Lazy<DateTimeOffset>(() => DateTimeOffset.UtcNow);

    /// <summary>
    /// Gets the current date and time in the UTC time zone.
    /// </summary>
    public DateTimeOffset UtcNow => _lazyUtcNow.Value;
}

这是一个好方法吗？有什么缺点？有更好的选择吗？

Answer 1

抱歉这里诉诸权威的逻辑谬误，但这很有趣:

约翰卡马克曾经说过:

There are four principle inputs to a game: keystrokes, mouse moves, network packets, and time. (If you don't consider time an input value, think about it until you do -- it is an important concept)"

来源: John Carmack's .plan posts from 1998 (scribd)

(我一直觉得这句话非常有趣，因为如果某件事对你来说似乎不对，你应该认真考虑直到它看起来对，这是只有主要极客才会说的建议。)

所以，这是一个想法: 将时间视为输入。 它可能不包含在构成 Web 服务请求的 xml 中(无论如何您都不希望它包含)，但在您将 xml 转换为实际请求对象的处理程序中，获取当前时间并使其成为一部分您的请求对象。

因此，由于在处理事务的过程中请求对象在您的系统中传递，因此始终可以在请求中找到被视为“当前时间”的时间。因此，它不再是“当前时间”，而是请求时间。 (它会是一回事，或者非常接近一回事，这一点完全无关紧要。)

这样，测试也变得更加容易:您不必模拟时间提供程序接口(interface)，时间始终在输入参数中。

此外，通过这种方式，其他有趣的事情变得可能，例如在与实际当前时刻完全无关的时刻为追溯应用的服务请求提供服务。想想可能性。 (bob squarepants-with-a-rainbow 的图片在这里。)