回调方法和维护 CultureInfo 和 ASP.Net HttpRuntime 的问题答案

【问题标题】：Issue with Callback method and maintaining CultureInfo and ASP.Net HttpRuntime回调方法和维护 CultureInfo 和 ASP.Net HttpRuntime 的问题
【发布时间】：2009-07-01 16:54:06
【问题描述】：

这是我的问题。我正在研究部署到多个欧洲国家的电子商务解决方案。我们将应用程序中的所有异常都保存到 SQL Server 中，我发现数据库中的某些记录将来会有 DateTime！

我们在 web.config 中定义文化，例如 pt-PT，并且预期的格式是 DD-MM-YYYY。

调试后，我发现数据库中这些“未来”记录的问题是因为我们使用了回调方法。例如，在我们的缓存架构中，我们使用回调，因此 -

CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest);

当我检查当前线程 CultureInfo 时，在这些回调上它是 en-US 而不是 pt-PT 并且 HttpContext 为空。如果回调发生异常，我们的异常管理器会将其报告为 MM-DD-YYYY，因此它会错误地保存到 SQL Server。

不幸的是，在异常管理器代码中，我们使用了 DateTime.Now，如果它不是回调就可以了。我无法将此代码更改为特定于文化，因为它在其他垂直领域共享。

那么，为什么 ASP.Net 中的回调不维护上下文？有没有办法在这个回调线程上维护它？这里有哪些最佳做法？

谢谢。

【问题讨论】：

标签： asp.net delegates callback httpruntime

【解决方案1】：

DateTime.Now 不依赖于文化。您是否将其保存为字符串？ ToString 确实取决于文化。

事实上，作为一般规则，尽量以不依赖于文化的方式将事物存储在数据库中。这在 Web 应用程序中尤其重要，其中每个请求的文化可能与下一个不同。为了能够“比较苹果和苹果”，你需要忽略文化。

【讨论】：

是的，它是 ToString。我同意应该忽略文化来存储在数据库中，但这是我必须处理的遗留代码。问题是因为回调丢失了 ASP.Net 上下文和应用程序文化。这就是我想尝试以某种方式解决的问题。
不知道这个回调是否发生在同一个请求的上下文中。如果是这样，那么您可以将文化存储在 HttpContext.Current.Items["CultureForRequest"] 中并在回调中将其拉出。

【解决方案2】：

您应该在日志管理中将日期时间（推荐 UTC）与错误描述的其余部分分开，并存储与日志条目相关的文化。然后你可以用这 3 个部分独立地重新组合信息。

缓存回调来自线程池线程，在您的情况下，该线程始终具有 en-US 并且没有 HttpContext。您应该能够通过将已删除的缓存项与您的回调逻辑相关联来检索文化。

【讨论】：