何时使用关系数据库结构？(When to use a relational database structure?)

 由于您正在使用MVC，因此使用一组不同的管道（再次）解析该项目，因此您需要在此处进行修补。 
 
 mvc.getPageItem管道中的GetFromRouteUrl处理器将mvc.getPageItem设置为与请求的URL匹配的项，然后最终将其设置为Context.Item ，因此它基本上将项重置为基于URL的“正确”项并覆盖你之前做出的改变。 
 
 您需要向mvc.getPageItem添加一个需要处理器，并使用一些逻辑来检查上下文项是否已经解析。 
 
 更新ItemResolver中的代码并存储一个布尔值以指示您已使用自定义逻辑解析，这节省了必须运行两次解析逻辑： 
 
public override void Process(HttpRequestArgs args)
{
  // some code
  Context.Item = dropLink.TargetItem;
  Context.Items["custom::ItemResolved"] = true;
}
 
 创建一个新类，检查您的自定义逻辑是否已解析该项： 
 
public class CheckItemResolved: GetPageItemProcessor
{
  public override void Process(GetPageItemArgs args)
  {
    if (args.Result == null)
    {
        var resolved = Sitecore.Context.Items["custom::ItemResolved"];
        if (MainUtil.GetBool(resolved, false))
        {
            // item has previously been resolved
            args.Result = Sitecore.Context.Item;
        }
    }

    return;
  }
}
 
 然后修补此： 
 
<pipelines>
  <mvc.getPageItem>
    <processor type="MyProject.Custom.Pipelines.CheckItemResolved, MyProject.Custom"
        patch:before="*[@type='Sitecore.Mvc.Pipelines.Response.GetPageItem.GetFromRouteUrl, Sitecore.Mvc']" />
  </mvc.getPageItem>
</pipelines>
 
 紧接着的管道是GetFromFromUrl() ，它通常args.Result通过重新解析Item来设置args.Result 。 通过将其设置回Context.Item，处理器将提前爆发并保留以前的逻辑。 
 
 您可以在文档中找到有关MVC和管道的更多详细信息。 

Since you are using MVC the item is resolved (again) using a different set of pipelines, so you need to patch into there instead.
 
The GetFromRouteUrl processor in the mvc.getPageItem pipeline sets args.Result to the item matching the requested URL which is then eventually set to Context.Item, so it essentially resets the item back to the "correct" item based on the URL and that overwrites the changes you made earlier.
 
You need to add a need processor to the mvc.getPageItem with some logic to check if the context item has already been resolved.
 
Update your code in the ItemResolver and store a boolean to indicate that you have already resolved using custom logic, this saves having to run the resolving logic twice:
 
public override void Process(HttpRequestArgs args)
{
  // some code
  Context.Item = dropLink.TargetItem;
  Context.Items["custom::ItemResolved"] = true;
}
 
Create a new Class that checks if your custom logic has already resolved the item:
 
public class CheckItemResolved: GetPageItemProcessor
{
  public override void Process(GetPageItemArgs args)
  {
    if (args.Result == null)
    {
        var resolved = Sitecore.Context.Items["custom::ItemResolved"];
        if (MainUtil.GetBool(resolved, false))
        {
            // item has previously been resolved
            args.Result = Sitecore.Context.Item;
        }
    }

    return;
  }
}
 
And then patch this in:
 
<pipelines>
  <mvc.getPageItem>
    <processor type="MyProject.Custom.Pipelines.CheckItemResolved, MyProject.Custom"
        patch:before="*[@type='Sitecore.Mvc.Pipelines.Response.GetPageItem.GetFromRouteUrl, Sitecore.Mvc']" />
  </mvc.getPageItem>
</pipelines>
 
The pipeline immediately after is GetFromFromUrl() which would normally set args.Result by re-resolving the Item. By setting it back to Context.Item that processor will break out early and leave your previous logic alone.
 
You can find more details about MVC and Pipelines in the documentation.