关于门户页面加载引擎的思考(上)

本文是一篇关于DNN页面生成引擎的随笔和思考，其中还会涉及到CommunityServer的皮肤机制、Url重写器和SharePoint的知识。在DNN，只有几页(。aspx)，除了核心机制，大部分业务逻辑都是用用户控件(。ascx)，那么DNN是如何展示千变万化的页面的呢？分析之后你会发现，所谓的千变万化的页面，不过是url重写器结合了一个页面加载(生成)引擎的结果。在这个加载过程中，主要步骤如下：1 .编写IHttpModule的扩展，捕获BeginRequest事件publiclclassurlrewrite模块3360i HTTP模块{ public string modulename { get { return ' URL rewrite Module }；}

: rgba(0, 0, 0, 1)">
    }
        
    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，哪一种更能体现用户需求。