CommunityServer系列之十一：优秀的URL重写机制

最近激情于对CS2的改造，疏于本系列的更新，一方面本身文章的受众比较有限，另一方面是自己的业余时间有限，着重于对CS的改造就必须放慢另外一方面的事情。
长话短说，简单说一下在CS2中的URL重写机制，CS2中的URL重写机制或者叫URL解决放案更贴切，我感觉是非常优秀的，虽然处理上复杂了些，但严格按照好的架构思想出来的应用具有非常好的扩展性。

不熟悉URLRewrite的可以参看http://www.microsoft.com/china/msdn/library/webservices/asp.net/URLRewriting.mspx?mfr=true

本文假设您已经基本了解了URL重写机制的基础上展开的。

通过web.config中的httpModules配置节我们了解到CS处理HttpModules的处理程序，在这里是当一个请求建立时最开始的事件，在这里，HttpModule处理程序不仅处理请求有关的操作还操作URLRewrite，具体的架构参见下面的UML图：



从此图了解一个大概即可，现简单描述一下处理过程：
当客户端请求到达IIS后，通过IIS把处理递交给HTTP处理程序（HttpModule），通过在HttpModule中注册的BeginRequest事件处理URLWrite，不过这里还使用了委托，委托CSContext来执行重写方法，在CSHttpModule中的方法调用UrlWriteProvider里的抽象函数获取匹配替换后的新的URL，要执行匹配，需要根据配置文件来筛选，在CS中有很多应用，如果在每个请求到达时都执行匹配，执行效率会很低的，CS在这里做了筛选，先根据URL判断其属于那个应用，这里叫Location，在配置节里的Locations就是设置这个的，这样判断了其所属的location后只需要匹配此Location下的URL即可，大大减少了匹配次数，当然这里还有一个URLMapping对应配置节的mappings（默认CSSDK中未配置这一项），这可以把一种location映射成为另一种location，这在扩展中也很有用，执行URL匹配时，通过正则表达式匹配配置节URL里的pattern，遇到匹配成功即可替换为vanity，当然生成URL的适合也是使用同一配置里的path，这样三个属性就构成了一个完整的URL配置。当然transformers配置节里是执行替换，这在最初读取配置的时候循环替换每个URL配置节里的Path和pattern，比如把##blogdirectory##替换为Pages/{0}/blog/，这样就使配置更灵活，如果需要修改Location的值将是很简单的一件事情。
举例来说，如果需要把CS中默认的URL（.aspx）改为.html结尾的URL，理论上只需要修改各URL中的path和pattern两个属性，注意：只能这两个属性同时出现的URL配置才能修改其扩展名，因为这样的URL才能执行重写。

注：以上十篇转载自

/article/4921394.html