Portal 页面加载引擎思考(上)

本文就DNN页面生成引擎随笔与思考，同时会牵涉到CommunityServer的Skin机制、Url Rewriter、SharePoint知识。
在DNN中，只有为数不多的几个页面(.aspx)，除去核心机制外，大多数业务逻辑都写在用户控件里(.ascx)，那DNN是如何展现出千变万化的页面的呢？分析之后，你会发现，所谓千变万化的页面只是url rewriter结合一种页面加载(生成)引擎综合的结果。在这个加载过程中主要按如下步骤进行：
1：编写一个IHttpModule的扩展，并且捕获其中的BeginRequest事件

public   class  UrlRewriteModule : IHttpModule
{
    public string ModuleName
    {
        get { return "UrlRewriteModule"; }
    }
        
    public void Init (HttpApplication application)
   {
        application.BeginRequest += new System.EventHandler(this.OnBeginRequest);
    }

    public void OnBeginRequest (object sender, EventArgs e)
    {
        //处理逻辑
    }
}

在Url Rewriter处理逻辑里，一般会用到正则表达式来进行Url 的匹配。以DDN为例子，几乎所有(但不是全部)的页面请求都被Rewriter到default.aspx页面，只是default.aspx后面的QueryStrings(url 问号后面的参数)不同(这很重要)。
2：有了上面的步骤，现在可以把焦点集中在default.aspx页面里，但是default.aspx页面里并没有放置所有的业务逻辑，而只有一个容器(placeholder一类的东西)，余下的就是加载用户控件(.ascx)到这个容器里了。DNN中采用了和CommunityServer类似的方式来加载用户控件(.ascx)，但显得没有CommunityServer高明，至少从MVC或MVP模式来看是这样。作为Portal，加载控件用户控件只不过是程序员理解的行为，从维护门户的管理人员来看，这还会复杂一些。在DNN中，在页面加载时，用户控件(.ascx)会被赋予不同的使命，有Skin，Container，以及Module(对于这几个词汇，我更喜欢这样称呼他:Skin-->Layout、Container-->Zone，Module-->Module or Part)。他们之间是存在包含关系的，Skin 就是页面的布局，在Skin中包含有一个或多个Container，Container中用来装载Module。 其实在sharepoint 中Container叫WebPartZone，而Module叫WebPart，这样似乎会好理解一些。
3：在第一个步骤里，我们得到一些 QueryStrings,有了他们就可以通过数据库或者配置文件去加载不同的Skin、Container与Module，而Skin通过public Control LoadControl (string virtualPath )来加载Container，同样，Container也通过它来加载Module。

至此，页面就被呈现给用户了。
有待进一步思考：
以上过程看似简单，但是要处理好这些URL还真不是件容易的事情，DNN中花费大量的代码来做URL处理与QueryStrings判断，但URL还是不够友好，而SharePoint显得在URL上美观很多。
效率问题，Portal大多访问量较大，类似DNN这样多嵌套与多用户控件的加载效率上不容乐观，SharePoint也有类似问题。
页面呈现的层次结构，DNN的Portal->Tab(Page)->Module或者SharePoint的Portal->Site->Page->WebPart，哪一种更能体现用户需求。