Asp.net MVC 覆盖 linq to sql 的默认 getter 和 setter，用于进行 UTC 转换
我的应用程序已经达到了一个阶段，我将尝试推出 UTC 支持。
我已经让一切正常工作，并且自己编写了两个实用程序类，名为convertToUtc 和convertFromUtc。我想你可以猜到他们是做什么的。
不过，我在想的是，我是否可以将这些构建到 linq-to-sql 创建的对象模型上的日期属性的 getter 和 setter 方法中，或者我应该在应用程序各处重新分配值的保存方式（添加一个控制器的额外行，例如
task.taskDeadline = Utility.ConvertToUtc(aspnet_Repository.GetUserGuid(User.Identity.Name), task.taskDeadline.Value);
如果有人可以告诉我，每次我需要用户 Guid 时我都会返回数据库，这会很酷，我想我会在某个地方缓存它，但这会很酷。需要在会议中举行或我认为
谢谢大家。
I'm getting to a point with my app where I'm about to try to roll out utc support.
I've already got it all working and have written myself two utility classes, called convertToUtc and convertFromUtc. I think you can guess what they do.
What I was thinking though, could I build these into the getter and setter methods for my date property on the linq-to-sql created object model, or should I just go round the app everywhere re assigning how the value is saved (adding an extra line to the controller like
task.taskDeadline = Utility.ConvertToUtc(aspnet_Repository.GetUserGuid(User.Identity.Name), task.taskDeadline.Value);
If anyone can tell me I'm doing something horrible by going back to the db each time I need the user Guid, that would be cool. I guess down the line somewhere I would cache it, but this would require holding it in session or something I presume.
Thanks all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该始终将日期时间作为 UTC 值（如果您知道对象的真实 UTC 时间）存储在数据库中，而不是作为本地时间值。
从 UTC 时间到本地时间的转换[主要]是一个渲染问题，应该在 UI 层中处理。
后一条规则的一个例外是，当您尝试按用户的日期时间进行分组时（例如昨天或上个月发生的事情），在这种情况下，UI 需要将时区传递到业务层，甚至可能传递到数据库为了执行按日期时间的本地表示分组的高效查询。
You should always store datetimes in your database as UTC values (if you know the true UTC time for the object) and NEVER as local time values.
The conversion from UTC time to localtime is [mostly] a rendering issue that should be dealt with in your UI layer.
One exception to this latter rule is when you are trying to GROUP by datetime for the user (e.g. what happened yesterday or last month) in which case the UI needs to pass the timezone down to the business layer, and maybe even to the database in order to execute an efficient query grouped by a local representation of the datetime.