C# 用于处理Sitecore中的虚拟项的嵌套通配符

TLDR；在多个级别上处理复杂虚拟项的最佳或推荐方法是什么

我目前正在做一件事，不使用查询字符串变量来过滤属性，我只想扩展URL并允许过滤这些URL。
事件：

~/events/2012/april

或

~/活动/午餐

或

~/events/6CB27D08-358E-49AA-8107-16A50E963C70

我目前有一个通配符设置来处理上一个案例或年份，但遇到了一个通配符只处理一个级别的问题，因此我无法用一个通配符处理

/events/{0}/{1}

。此外，我相信常见的友好url最终将是

/events/2012/april/\uuu

使用通配符，我需要将它们放在三层深的地方，用三种不同的布局来处理我目前所知道的每种情况

Events/
        *
          *
            *

---

是否有更好的方法或更推荐的方法在多个级别上处理复杂的虚拟项？

您在这里的路径正确，您的正确之处在于，URL的每个段都需要一个通配符项。然而，通配符的存在并不意味着您需要使用它。换句话说，

/events/*/*

项将处理

/events/2012/april

URL

---

你可能想看看这篇博客文章，这篇文章引出了

是否有使用通配符项的具体原因？ 我认为，如果你对URL的深度超过1级，那么你最好还是重写URL 通配符

---

因此，只制作

/events

项，并将

/events/{0}/{1}

重写为

/events？year={0}&month={1}

我开始使用通配符项，因为我的事件不是系统中的项，而是基于外部存储的API的项，所以这是一种为事件提供URL的简单方法，您知道如何使用Sitecore进行URL重写吗？当规则被启用时，它只会中断Sitecore页面（我假设Sitecore首先运行请求，而不是URL重写模块）。根据我的经验，IIS重写模块在Sitecore管道之前执行。（我的规则中确实启用了stopProcessing=“true”，但这不应影响Sitecore）仍然坚持以这种方式处理我的案例三次。似乎与

*

的意思相反，但我相信Sitecore这样做是有原因的。我真的很喜欢通配符模块，因为配置会保留在Sitecore中，而不是配置文件中。通配符模块最初对我们很有效，但无法与站点上的其他导航控件很好地配合。