C# 如何使用Windows Azure实现URL重写？

我有一个ASP.NET/C网站，它托管在Windows Azure上。该网站是一个基于预测的社交网站，主页上有预测摘要提要。如果单击摘要，您将使用简单的查询字符串重定向到该预测的详细信息页面

例如：

这个特别的预测题为“帕丽斯·希尔顿将获得诺贝尔和平奖”，所以我想做的是在Azure上为我的网站实现URL重写，如下所示：

有哪些策略和最佳实践可以做到这一点？有人能给我指出一两篇关于Azure的文章吗

加上连字符的标题（“paris hilton bla bla”）实际上只是为了让URL更具可读性；我不打算在加载页面方面依赖它。事实上，我可能会允许重复的标题，因为我将依赖URL中的预测ID

编辑：

忘了提到我们不是基于MVC的。我们提出了我们自己的体系结构，它使用PageMethods和WebMethods将JSON返回给客户端。我们依靠ASP.NET AJAX完成所有JSON序列化，并且几乎所有的UI都是使用jQuery在客户端上动态构建的

编辑：解决方案

我想我会分享我的解决方案，现在我已经开始运行了

我创建了一个新类，如下所示（从某处逐字复制）：

然后，我在system.webServer块的web.config中添加了以下内容：

   <!-- Added for URL Routing -->
   <modules runAllManagedModulesForAllRequests="true">
      <add name="UrlRoutingModule"
           type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
   </modules>

    <!-- Added for URL Routing -->
    <handlers>
      <add name="UrlRoutingHandler"
           preCondition="integratedMode"
           verb="*"
           path="UrlRouting.axd"
           type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
   </handlers>

现在，当我需要读取路由值（如预测ID）时，我会执行以下操作：

  long _predictionId = System.Convert.ToInt64(WebAppUtils.GetRouteDataValueAsNumber(Request, "id"));

很好！现在，我的网站感觉像一个MVC应用程序，有友好的、自我记录的URL

哦，最后一件事，您还需要启用HTTP重定向，如下所示：

---

开始=>控制面板=>程序=>打开Windows功能=>Internet信息服务=>万维网服务=>通用HTTP功能=>（选中）HTTP重定向复选框。

实现这一点的最简单方法是使用

System.Web.Routing

程序集的编程方法

这主要是通过在

web.config

中包含

UrlRoutingModule

，并定义基于匹配路由解析目标页面的模式来实现的。如果您熟悉ASP.NET MVC，那么您以前使用过这种路由策略，但MVC不一定要使用路由

以下是一些帮助您入门的资源：

• -正式文件

• -*请注意，本文在ASP.NET MVC应用程序的上下文中解释了路由，但是，无论您是否使用MVC，相同的方法都会起作用

• -解释性文章

• -解释如何独立于MVC架构使用路由的案例研究

关于Windows Azure。。。

---

如果您采用这种方法，那么您是否使用WindowsAzure其实并不重要。然而，我发现了一个例子，解释了如何在WindowsAzure上轻松部署这样的解决方案。文章甚至有一个.

Azure web角色安装了IIS7 Url重写模块-

此模块的“操作方法”位于

对于Paris示例，基本上需要设置映射url的规则

到

这有点像：

模式-

^predictions/([0-9]+)/([_0-9a-z-]+)

行动-

 details.aspx?id={R:1}

---

有关定义这些规则的更多信息，请参见

感谢您的宝贵反馈。非常感谢。我知道如果我们是基于MVC的，这会容易得多。然而，我们提出了我们自己的框架，它利用基于JSON的WebMethods和PageMethods以及通过jQuery进行的客户端呈现，因此您不依赖MVC的链接将特别有用。@Armschair Bronco，我发布的所有链接都包含不依赖MVC的代码。我知道你没有使用MVC。我之所以发布这些文章，是因为特定于MVC的文章展示了最具可读性的路由API示例。我记得我在早期评估MVC时，我们试图确定一个体系结构。它让我想起了很多以前的ASP时代，它严重依赖于alligator标签，我说：“算了吧！想起那些日子让我头疼。”你提供的链接是一个很好的起点，所以竖起大拇指。一个问题是，忽略人类可读的连字符标题是否被视为“最佳实践”？换句话说，我们是应该依赖一个ID，还是应该实现一些保证每个标题都是唯一的东西，然后改用它？@Armchair Bronco，检查这个链接：。显然，有一些成功的网站使用ID并忽略带连字符的slug。当然，如果url依赖于整数ID，那么记住url肯定会更困难，但我怀疑人们无论如何都不会记住关于帕丽斯·希尔顿获得诺贝尔和平奖的url。无论哪种方式，你都可以在你的应用程序运行良好后，扩展路由分辨率。虽然如果帕丽斯·希尔顿奇迹般地获得了诺贝尔和平奖，那么所有的赌注都将落空！它将成为互联网上最热门的URL！：-）谢谢你的真实例子。看起来做这件事比我想象的要容易。6个月前，当我第一次尝试使用我的服务器时，我在这方面遇到了一些问题，但现在我们在Azure上安装了生产和暂存服务器，我打赌事情会顺利得多。如果您的本地主机服务器出现问题，那么可能会尝试使用IIS Express。在使用Azure之后，我会拿你的钱打赌；）不可否认的是，Azure并没有让这些东西变得“微不足道”，但没有什么比试图强迫自己表现得像网络上的某个东西更糟糕的了。Azure的美妙之处在于能够针对您的登台服务器进行工作，解决所有问题，并翻转开关。Presto-change-o，舞台服务

<!-- Url routing -->
<location path="predictions">
   <system.web>
      <authorization>
         <allow users="*" />
      </authorization>
   </system.web>
</location>

  public static int GetRouteDataValueAsNumber(HttpRequest request, string propertyName)
  {
     if ((request == null) ||
         (request.RequestContext == null) ||
         (request.RequestContext.RouteData == null) ||
         (request.RequestContext.RouteData.Values[propertyName] == null))
     {
        return -1;
     }

     try
     {
        return System.Convert.ToInt32(request.RequestContext.RouteData.Values[propertyName]);
     }
     catch
     {
     }

     return -1;
  }

  long _predictionId = System.Convert.ToInt64(WebAppUtils.GetRouteDataValueAsNumber(Request, "id"));

^predictions/([0-9]+)/([_0-9a-z-]+)

 details.aspx?id={R:1}