系统中动态评估日期的最佳实践？

Question

让我向你们介绍一个极简的和虚构的案例与真实的时间顺序，更新和问题。

只有ID的

用户

我有一个系统，它只有User实体和ID列。因此，有一个类User和SQL表Users：

[Table("Users")] // database table
public class User
{
    [Key]
    [Column("Id")] // database column
    public long Id { get; set; } 
}

新特性

有一天，一位产品负责人来找我，请我介绍四个新特性：

• 生日
• 年龄成熟(18 y.o.(及以上)
• 订阅截止日期(付款至)日期
• 是活动的，这意味着订阅尚未过期。

当然，首先我建议不要储存“年龄成熟度”和“是活跃的”，因为它是一个次要的评估值。

然而，业务分析师告诉我:好的，按您的方式去做，但是我们需要看到\ export，列出所有用户的成熟度和活跃状态，最多有10000个用户。

现在，我看到了3种解决方案，并且无法从体系结构、性能和未来可支持性的总结评估来决定哪种方案更好。

可能的解决方案

1.域模型

中的可评估属性

[Table("Users")] // database table
public class User
{
    [Key]
    [Column("Id")] 
    public long Id { get; set; } 

    [Column("Birthday")] 
    public DateTime Birthday { get; set; }

    public bool IsMature 
    {
        get { return (DateTime.Now - Birthday).Years > SystemCfg.MaturityAge; }
    }

    [Column("PaidUntil")] 
    public DateTime? PaidUntil { get; set; }

    public bool IsActive
    {
        get { return PaidUntil.HasValue && PaidUntil.Value >= DateTime.Now; }
    }
}

优点：

• 实际价值:价值总是实际的。
• 业务逻辑布局:业务逻辑存储在一个地方。

缺点：

• 性能:在实际示例中，PaidUntil实际上是一个需要花费一定时间来计算的属性，有时需要使用web请求，因此为10000用户动态计算它在将来可能会变得非常缓慢。

2.数据库存储的属性，在

中重新计算

[Table("Users")] // database table
public class User
{
    [Key]
    [Column("Id")] 
    public long Id { get; set; } 

    [Column("Birthday")] 
    public DateTime Birthday { get; set; }

    [Column("IsMature")] 
    public bool IsMature 

    [Column("PaidUntil")] 
    public DateTime? PaidUntil { get; set; }

    [Column("IsActive")]
    public bool IsActive { get; set; }
}

// on sign in:
user.IsMature = (DateTime.Now - user.Birthday).Years > SystemCfg.MaturityAge;
user.IsActive = PaidUntil.HasValue && PaidUntil.Value >= DateTime.Now;
_userRepository.Update(user);

if (!user.IsActive)
    return AuthResult.UserIsInactive;

优点：

• 性能:只有在登录时才会重新计算值，这将在这些选项中获得最佳性能。

缺点：

• 业务逻辑布局:业务逻辑存储在一个地方，但模型现在已经贫血。
• 实际值:对于报表/导出视图来说，值大多不是实际值，因为在

3.按计划

重新计算的数据库存储属性

相同的模型，但数据是由一个特殊的Windows服务更新的，它通过我的数据库运行，并保持数据的最新。

优点：

• 性能:值是在单独的线程/应用程序/服务器上计算的
• 实际值:确保值为实际值，直到更新服务器重载或停机为止。

缺点：

• 业务逻辑布局:业务逻辑存储在单独的、非域应用程序中。
• 这种方法听起来很奇怪

那么，对于这种特殊情况，我应该使用什么方法呢？

你和人们通常使用什么方法？

Answer 1

您的第一个解决方案:计算域模型是最好的。

实际上，虽然这里有两种类型的计算字段。取决于您查看对象的日期而更改的对象和取决于系统事件(paidUntilDate)的更改的

字段的变化取决于你看它们的时间，必须实时计算，否则就有过时的危险。导出在其生成的第二天将是不正确的，您可能应该在可能的情况下尝试避免这样的字段。

但是，当发生更改的事件时，应该计算PaidUntilDate。大概是当客户购买订阅时。

这就解决了你冗长的计算问题。也许您可以直接连接订阅表而不是calc。