创建日期 - 该值应该在 BL 还是 DAL 中设置？
日期创建了一个我感兴趣的特定示例 - 但还有其他属于同一类别的数据：您想要捕获有关任何模糊重要实体的数据。
在哪里最好做到这一点：业务逻辑（BL）还是数据访问层（DAL）？
到目前为止，我一直依赖 SQL Server 的 getdate() 来填充在插入表时为我创建的日期，但现在我开始怀疑是否应该在 BL 中做更多的事情。
仅供参考 - 这主要是在基于 Web 的系统中，您在 BL 中创建一个对象（基于用户输入）并在 DAL 上触发它 - 这并不是我多年来一直想引用内存中的对象（因此，在对象上具有“创建日期”属性以在创建对象时在 BL 中使用并不是问题）。
也许还有第三种选择 - 在阅读 Marr75 的答案后，我想到在某些情况下记录两次可能会有用（在两个位置记录一次）。您将获得数据层中一致的日期/时间的好处，但您仍然有一个 BL 驱动的值可供参考 - 我想我会取决于您的用例。不过，这种选择并非没有风险——人们可能会开始使用错误的日期来做错误的事情。
Date Created a specific example I'm interested in - but there are other bits of data that fall into the same category: data which you'd want to capture about any vaguely important entity.
Where best to do this: business logic (BL) or Data Access layer (DAL)?
Until now I've relied on SQL Server's getdate() to populate the date created for me on insert into the table, but now I'm starting to wonder if I should be doing this more in the BL.
FYI - this has mainly been in web-based systems where you create an object in the BL (based on user input) and fire it off at the DAL - it's not like I've been wanting to refer to the object in memory for ages (so having a "date created" property on the object for use in the BL on creation of the object hasn't been an issue).
Perhaps there's a third option - it occurs to me after reading Marr75's answer that recording it twice might be useful in some senarios (once in both locations). You'd get the benefit of a consisent date/time in the data layer but you'd still have a BL driven value to refer to as well - I guess i'd depend on your use cases. This option isn't without some risk, though - people might start using the wrong date for the wrong thing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我始终投票支持 DAL。过去，依赖数据库之外的层的日期和时间一直是我的错误来源。在大多数设置中，您很可能保证数据库中的日期和时间一致。客户端-服务器甚至服务器-服务器的时间同步问题导致了令人讨厌的、难以复制、难以修复的问题。
I vote for always the DAL. Relying on dates and times from layers beyond the database has been a source of bugs for me in the past. In most setups, you're more than likely guaranteed a consistent date and time out of your database. Time synchronization issues client - server and even server - server have resulted in nasty, hard to duplicate, hard to fix problems.
我会说：是的。
也许养成在 BL 中设置创建日期和最后访问日期的习惯。然后在您的 DAL 中，始终检查这些字段中的空值。如果它们为空，请考虑您的选择：抛出异常，或者只是在该层填充这些值。在插入/更新之前有点包罗万象。
我的模式与您在问题中描述的相同。然后，我面临着让应用程序使用/消耗 UTC 时间戳的问题，我想我只需将该行为移至 BL 和/或 DL 类即可。是的，我可以使用
GETUTCDATE()，但感觉在 BL/DL 中使用此逻辑更合适。I'd say: yes.
Perhaps get into the habit of setting the created and lastaccessed dates in your BL. Then in your DAL, always be checking for nulls in those fields. If they're null, consider your option: throwing an exception, or just filling in those values at that layer. Kind of a catch-all before insert/update.
I've had the same pattern as you describe in your question. I then was faced with having the application use/consume UTC timestamps, and I figured I'd just move that behaviour to the BL and/or DL classes. Yes, I could've used
GETUTCDATE(), but it just felt more appropriate to have this logic in the BL/DL.