关于业务开发的操作时间处理方案

业务日期工作流的表现特征

• 流水性
  依照业务操作先后，时间按照流水线记录
  例如：某审核日志

  • 2024-01-01 12:12:01 提交成功
  • 2024-01-01 12:12:02 审核成功

• 业务操作单元操作内时间固定
  依照业务操作单元的划分，同一操作单元内保持业务时间一致

例如：某审核明细

• 2024-01-01 12:12:01 批次 222-1 提交成功
• 2024-01-01 12:12:01 批次 222-2 提交成功
• 2024-01-01 12:12:02 批次 222-1 审核成功
• 2024-01-01 12:12:02 批次 222-2 审核成功

可能会导致发生时间错位的设计：

1. 数据库业务操作单元操作内部使用SQL决定操作时间:

XXXDao
InsertData(){ 
	var sql = "insert into createtime = getdate() ....";
	.....
} 

2. 业务操作单元内部子方法内部获取当前时间决定操作时间:

XXXService
{
	AddOrderLog(){ 
		var currtime = datetime.now; 
		InsertOrderLog(data, currtime);
	}
}

推荐的做法：
判断业务操作单元，在操作单元入口做统一的日期获取处理.

比如：某个业务审核属于操作单元，那么需要在审核控制器决定审核时间

XXXController { Audit() { var optTime = datetime.now; xxxSerice.Audit(optTime)} }
xxxSerice { Audit(optTime) {  Audit(optTime); AddAuditLog(optTime);} }

比如：业务的操作需要两个操作单元的操作来完成，那么需要在业务操作单元方法入口决定业务操作时间

XXXController { 
	Pay() { 
		xxxSerice.Pay()
	} 
}
xxxSerice { 
	Pay() {  
		accountService.AccountPay(); 
		orderService.OrderPay();
	} 
}
accountService { 
	AccountPay() { 
		var optTime = datetime.now; 
		Pay(optTime); 
		AddAccountPayLog(optTime);
	} 
}
orderService { 
	OrderPay() { 
		var optTime = datetime.now; 
		Pay(optTime); 
		AddOrderPayLog(optTime);
	} 
}

这样，我们看到用户在2024-01-01 12:12:01支付了订单
扣款时间和扣款日志时间一致
订单支付时间和订单支付日志时间一致
保证了单一操作单元内的时间一致性

那么获取时间，var optTime = datetime.now; 是否是一个最佳实践？
例如在非单一时区体系内，例如UTC可能会导致很多问题。

我们可以引入Provider组件，通过Action生命周期控制注入使用类中，而非获取服务器时间或者用户传递的不可信时间来决定业务的发生时间。
由此最终获取时间应该是：
例如：

xxxSerice {  
	Pay() { 
		var optTime = _localDateProvider.getCurrTime();
	} 
}

通过Options配置provider的功能实现:
例如：

options => options.IsUTC = true;

由此，可以在实现localDateProvider的时候，自由决定getCurrTime的取值逻辑，根据options来决定表现特性，也可以通过时钟服务器获取操作时间等等，可拓展和便利性更强。