【问题标题】:How Can I Stop ASP.Net MVC Html.ActionLink From Using Existing Route Values?如何阻止 ASP.Net MVC Html.ActionLink 使用现有的路由值?
【发布时间】:2009-11-30 01:13:34
【问题描述】:

我正在处理的网站有一些相当复杂的路由结构,我们在使用路由引擎以我们需要构建 URL 的方式构建 URL 时遇到了一些困难。

我们有一个搜索结果页面,它使用基于 RegEx 的模式匹配将多个变量分组到单个路由段中(即“www.host.com/{structuralParameters}”可以如下:“www.host.com/variableA -variableB-variableC" - 其中变量 A 到 C 都是可选的)。经过一些工作,这对我们来说很好。

我们遇到的问题解决了 ActionLink 方法的一个烦人的特性:如果你指向同一个控制器/动作,无论你是否想要它们,它都会保留现有的路由值。我们更愿意控制链接的外观,并且在某些情况下,不能保留现有参数。一个例子是我们网站的主导航指向一个没有设置参数的搜索结果页面 - 如果您愿意,可以使用默认搜索页面。我说这是一个令人讨厌的功能,因为它是 ASP.Net MVC 框架的一个罕见实例,似乎在没有明显扩展点的情况下指示实现 - 我们不希望创建自定义 ActionLink 代码来在我们的母版页中编写简单的导航链接!

我看到有人说您需要将此类参数显式设置为空字符串,但是当我们尝试这样做时,它只是将参数从路由值更改为查询字符串参数。在我看来,我们应该被要求明确排除我们没有作为参数明确传递给 ActionLink 方法的值,但如果这是我们唯一的选择,我们将使用它。但是目前如果它显示在查询字符串中,那么它对我们来说就像直接将参数放入路由中一样无用。

我知道我们的路由结构加剧了这个问题 - 如果我们使用更简单的方法(即 www.host.com/variableA/variableB/variableC),我们可能不会遇到任何问题,但我们的 URL 结构是不可协商的- 它旨在满足与可用性、搜索引擎优化和链接/内容共享相关的非常具体的需求。

我们如何使用 Html.ActionLink 生成页面链接而不依赖于当前的路由数据(或者,如果可能,需要明确排除路由段),即使这些链接导致相同的操作方法?

如果我们确实需要明确排除路由段,我们如何防止该方法将路由呈现为查询字符串参数?

这个看似很小的问题却给我们带来了极大的悲痛,我将感谢您为解决它提供的任何帮助。

编辑:按照 LukLed 的要求,这是一个 ActionLink 调用示例:

// I've made it generic, but this should call the Search action of the 
// ItemController, the text and title attribute should say "Link Text" but there
// should be no parameters - or maybe just the defaults, depending on the route.
// 
// Assume that this can be called from *any* page but should not be influenced by
// the current route - some routes will be called from other sections with the same
// structure/parameters.
Html.ActionLink( 
    "Link Text",
    "Search", 
    "Item", 
    new { }, 
    new { title = "Link Text" } 
);

【问题讨论】:

  • 你能举一个调用ActionLink函数的例子及其结果吗?你写了很多,但我觉得这个例子会更好地解释它。
  • 已添加示例 ActionLink。如您所见,我在匿名对象中未提供任何参数(我们已尝试将它们显式设置为空字符串)。

标签: asp.net-mvc routing actionlink


【解决方案1】:

在调用 Html.ActionLinkHtml.RouteLink(或任何 URL 生成方法)时将路由值设置为 null 或空字符串将清除“环境”路由值。

例如,使用标准 MVC 控制器/动作/id 路由,假设您位于“Home/Index/123”。如果你调用Html.RouteLink(new { id = 456 }),那么MVC 会注意到controller="Home"action="Index" 的“环境”路由值。它还会注意到id="123" 的环境路由值,但它会被显式的“456”覆盖。这将导致生成的 URL 为“Home/Index/456”。

参数的顺序也很重要。例如,假设您拨打了Html.RouteLink(new { action = "About" })。 “关于”动作将覆盖当前的“索引”动作,而“id”参数将被完全清除!但你问为什么?因为一旦你使一个参数段失效,那么它之后的所有参数段都将失效。在这种情况下,“action”被一个新的显式值无效,因此紧随其后且没有显式值的“id”也被无效。因此,生成的 URL 将只是“Home/About”(没有 ID)。

在同样的情况下,如果您调用Html.RouteLink(new { action = "" }),则生成的 URL 将只是“Home”,因为您使用空字符串使“action”无效,然后导致“id”也无效,因为它在无效的“动作”之后出现。

【讨论】:

  • 我无法重现您在帖子中所说的这种行为。我有 Html.ActionLink("abc", "actionA",new{docid= 4, id=5}) 并且在我渲染链接时在此页面上 Html.ActionLink("xyz", "actionB" , new{id=90 }) 根据您的解释,它应该清除 docid,因为我更改了操作参数,但它没有清除 docid 并在链接生成中使用它。我在这个环境值问题上遇到了很多麻烦。使用 .NET 4 和 mvc2
  • @Muhammad,参数清除的东西取决于最终选择生成的路线。如果在该路由中 {docid} 参数出现在其他已更改的参数之前,则环境值将保持不变。如果您可以分享您的代码,我可以对此进行调查。我建议在 StackOverflow 上打开一个新问题,然后从此处链接到它(请务必在评论中提及@Eilon,以便它通知我!)。
  • 是的,你告诉的行为是正确的。只是,我有点误会了。我已经在这里发布了我的代码以及stackoverflow.com/questions/3475981/… 的问题。请看一下
  • +1 对于默认路由和参数失效,我想不出更好的解释了。
  • 这个答案在 6 年后仍然相关,但第一个重载已更改为需要 2 个参数,第一个是链接文本。这会改变 Html.RouteLink(" ", new { action = "" }) 的最小答案
【解决方案2】:

解决问题的根源

似乎最佳解决方案(闻起来不像是一种变通方法)是解决问题的根源并且在路由中的解决方案。

我编写了一个名为 RouteWithExclusions 的自定义 Route 类,它能够定义在生成 URL 时应该排除/删除的路由值名称。问题是当路由通过路由表并且后续路由没有相同的路由值名称时......

整个问题在my blog post 中有详细说明和解释,所有代码也在那里提供。检查一下,它可能会帮助您解决此路由问题。我还编写了两个额外的 MapRoute 扩展方法,它们采用额外的参数。

【讨论】:

    【解决方案3】:

    如果您想完全控制链接,只需自己构建链接:

    <a href="~/variableA/variableB/<%= Html.Encode(Model.Target) %>">Click Here</a>
    

    href 属性中替换您需要的任何内容。

    【讨论】:

    • 是的,这是一个选项 - 为了节省时间,当然值得考虑。我对这种方法的担忧是,我们将来可能需要更改我们的路线,最好在路线字典中执行此操作而不是每个单独的视图 - 即使只有少数视图受到影响。它为人为错误留下了更多导致错误的机会......无论如何,这可能是这种情况下的最佳选择。
    • 嗯,听起来您希望它只遵循部分路线。为此,您必须筛选路由字典并从中构建一个 URL。
    • 为了记录,您可能不需要 URL 中的所有这些斜线来获得良好的 SEO。在浏览器中查看此页面的 URL。 StackOverflow 搜索引擎优化是最好的。
    • 是的,我开始认为我需要按照您对路线字典的建议做一些事情。可能封装在自定义 ActionLink 扩展方法中。 StackOverflow 在优化他们的网站方面做得非常出色——为什么他们会一直出现在我的搜索结果的顶部? ;-) 然而,他们网站上的内容结构确实比我们更清晰——我们无法改变这一点。据我了解,我们的 URL 策略是合理的(我们最近在这方面投入了大量工作),但它确实使事情变得复杂。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-13
    • 2018-08-23
    • 2010-10-17
    相关资源
    最近更新 更多