专门为代表 Now 的 DateTime 制作一个包装器是个好主意吗？

我最近注意到，为了模拟和测试目的，使用代表“现在”的 DateTime 作为方法的输入参数确实很好。而不是每个方法都调用DateTime.UtcNow他们自己，我在上面的方法中执行一次，然后将其转发到下面的方法中。

所以很多需要“现在”的方法都有一个输入参数DateTime now.

（我正在使用 MVC，并尝试检测一个名为now并将 DateTime.UtcNow 模型绑定到它）

所以而不是：

public bool IsStarted
{
    get { return StartTime >= DateTime.UtcNow; }
}

我通常有：

public bool IsStarted(DateTime now)
{
    return StartTime >= now;
}

所以我现在的惯例是，如果一个方法有一个DateTime参数称为now，你必须用当前时间来喂养它。当然，这取决于约定，其他人可以轻松地将其他日期时间作为参数放入其中。

为了使其更加坚固和静态类型，我正在考虑将 DateTime 包装在一个新对象中，即 DateTimeNow。所以在最上层之一我将转换DateTime to a DateTimeNow当有人尝试修改正常的日期时间时，我们会收到编译错误。

当然，你仍然可以解决这个问题，但至少你会感觉自己做错了什么。 还有其他人走过这条路吗？从长远来看，是否有任何我没有考虑到的好或坏结果？

您可以创建具有必要属性的接口。即IClock并将其作为依赖项注入。

interface IClock
{
    DateTime Now { get; }
    DateTime UtcNow { get; }
}

class SystemClock : IClock
{
    public DateTime Now { get { return DateTime.Now; } }
    public DateTime UtcNow { get { return DateTime.UtcNow ; } }
}

class TestDoubleClock : IClock
{
    public DateTime Now { get { return whateverTime; } }
    public DateTime UtcNow { get { return whateverTime ; } }
}

这样你就可以轻松地对你的代码进行单元测试，这取决于DateTime。通过DateTime.Now到处都是参数听起来很糟糕。如果你需要怎么办Now并且UtcNow还有其他什么？您会仅为此目的添加三个参数吗？

我建议使用这种接口技术来避免带有太多参数的丑陋代码，这对您没有多大帮助。