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才能执行重写。

posted on 2006-06-27 00:01  dragonpro  阅读(5104)  评论(10编辑  收藏  举报

Free Web Counter