Question

我只是在必要时尝试在管道“httpRequestBegin”中执行某些操作。我的处理器在Sitecore解析用户（处理器类型=“Sitecore.Pipelines.HttpRequest.UserResolver，Sitecore.Kernel”）之后执行，因为如果Sitecore无法首先解析它，我也会解析用户。

后来，我想在管道“insertRenderings”中添加一些渲染，只有在前一个管道中的操作被执行时（如果我解析了用户，显示一条消息），所以我试图保存一些“标志”在第一步，检查第二步。我的问题是，我在哪里可以存放那面旗帜？我试图找到某种“按请求”缓存......

到目前为止，我已经尝试过了：

会话：错了，现在还太早，会话还不存在。
Items（HttpContext.Current.Items）：它也不起作用，我的项目在秒步骤中不存在。

到目前为止，我正在使用具有一些唯一键的应用程序缓存（HttpContext.Current.Cache），但我不喜欢这个解决方案。

任何人都知道更好的方法来分享这个“旗帜”吗？

Answer 1

您可以在请求标头中添加一个标志，然后检查它在后面的管道中是否存在，例如

// in HttpRequest pipeline
HttpContext.Current.Request.Headers.Add("CustomUserResolve", "true");

// in InsertRenderings pipeline
var customUserResolve = HttpContext.Current.Request.Headers["CustomUserResolve"];
if (Sitecore.MainUtil.GetBool(customUserResolve, false))
{
    // custom logic goes here
}

这感觉很少脏，我认为添加到Request.QueryString或Request.Params会更好，但这些是只读的。但是，如果您只需要一次性交易（即仅在第一次解决时），那么它将起作用，因为在下一个请求中，Headers将恢复为默认状态而不添加您的自定义标头。

Answer 2

HttpContext.Current.Cache或HttpRuntime.Cache可能是此处最快的解决方案。虽然这种方法在AppPool被回收时不会保留数据。如果只向缓存添加几个密钥然后维护它们，则此解决方案可能适合您。如果每个请求都将一个条目放入缓存中，它最终可能会长时间溢出工作进程使用的内存。

作为替代方案，您可以尝试使用Sitecore.Context.ClientData属性。它使用ClientDataStore，它使用数据库（在clientDataStore文件中查找web.config部分）来存储数据。这些条目可以在AppPool回收中存活。虽然如果你经常使用它们，当你需要写入和/或读取条目时，它可能成为负载下的瓶颈。如果您确实知道可能有很多条目是为了共享目的而创建的，那么我将创建一个计划任务来清理过时条目中的数据存储。

Answer 3

我知道这是一个非常老的问题，但我只想解决我遇到的问题

以下将按http请求保存数据。 HttpContext.Current.Items [“ ModuleInfo”] =“自定义模块信息”

我们可以在一个sitecore管道中将数据存储到httpcontext，然后在另一个Sitecore管道中进行检索...

https://www.codeproject.com/Articles/146455/When-Can-We-Use-HttpContext-Current-Items-to-Store

跨Sitecore管道共享数据

3 个答案: