Architecture 创建日期-该值应在BL或DAL中设置？

Date创建了一个我感兴趣的特定示例，但还有其他一些数据属于同一类别：您希望捕获的关于任何模糊重要实体的数据

在哪里做得最好：业务逻辑（BL）还是数据访问层（DAL）

到目前为止，我一直依赖SQL Server的

getdate（）

将在插入时为我创建的日期填充到表中，但现在我开始怀疑我是否应该在BL中做得更多

仅供参考-这主要是在基于web的系统中，您在BL中创建一个对象（基于用户输入）并在DAL中启动它-这不像我多年来一直希望在内存中引用该对象（因此在对象上有一个“date created”属性，以便在创建对象时在BL中使用，这不是一个问题）

---

也许还有第三种选择——在读了Marr75的答案后，我想到在一些senarios（两个地点各记录一次）中记录两次可能有用。您可以从数据层中获得一致的日期/时间，但您仍然可以参考BL驱动的值-我想这取决于您的用例。不过，这个选项也不是没有风险的——人们可能开始用错误的日期做错误的事情。

我总是投票支持DAL。过去，依赖数据库以外的层的日期和时间一直是我的一个bug来源。在大多数设置中，很可能保证数据库的日期和时间一致。客户端-服务器甚至服务器-服务器的时间同步问题导致了令人讨厌的、难以复制的、难以修复的问题。

我想说：是的

也许养成在BL中设置创建日期和上次访问日期的习惯。然后在DAL中，始终检查这些字段中的空值。如果它们为NULL，请考虑您的选择：抛出异常，或者只填充该层中的值。在插入/更新之前有一种包罗万象的感觉

---

我的模式和你在问题中描述的一样。然后，我面临着让应用程序使用/使用UTC时间戳的问题，我想我应该将这种行为转移到BL和/或DL类。是的，我本可以使用

GETUTCDATE（）

，但我觉得在BL/DL中使用这个逻辑更合适。

我同意你的想法-但将这个责任放入BL的原因之一肯定是因为你有你想要执行的规则-比如没有空值。是不是BL不在乎但数据库在乎？