Portal page loading engine (I)

This article describes the DNN page generation engine as an example. It also involves knowledge about the Skin mechanism, Url Rewriter, and SharePoint of CommunityServer.
In DNN, there are only a few pages (. in addition to the core mechanism, most business logic is written in the user control (. ascx), how does DNN display ever-changing pages? After analysis, you will find that the ever-changing page is the result of combining url rewriter with a page loading (generation) engine. Perform the following steps during the loading process:
1: Write an IHttpModule extension and capture the BeginRequest event.

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)
{
// Processing logic
}
}

In the Url Rewriter processing logic, regular expressions are generally used for Url matching. Taking DDN as an example, almost all (but not all) page requests are Rewriter to default. aspx page, only default. the QueryStrings (parameters after the url question mark) after aspx is different (this is important ).
2: with the above steps, you can focus on default. in the aspx page, but default. the aspx page does not contain all the business logic, but only one container (such as placeholder), and the rest is to load the user control (. ascx) to this container. DNN uses a method similar to that of CommunityServer to load User Controls (. ascx), but it does not appear that the CommunityServer is brilliant, at least in the MVC or MVP mode. As a Portal, the loading of control user controls is only a behavior that programmers understand. From the perspective of the management personnel who maintain the Portal, this is complicated. In DNN, when a page is loaded, the user control (. ascx) will be assigned different missions, including Skin, Container, and Module (for these words, I prefer to call him Skin --> Layout, Container --> Zone, module --> Module or Part ). There is an inclusive relationship between them, and Skin is the layout of the page. Skin contains one or more iner, which is used to load the Module. In sharepoint, Container is called WebPartZone and Module is called WebPart, which seems to be better understood.
3: In the first step, we get some QueryStrings. With them, we can load different Skin, iner, and Module through the database or configuration file, skin uses public Control LoadControl (string virtualPath) to load the Container. Similarly, the Container also uses it to load the Module.

Now, the page is displayed to the user.
Further consideration is required:
The above process seems simple, but it is really not easy to handle these URLs. DNN spends a lot of code to process the URL and QueryStrings, but the URL is still unfriendly, sharePoint looks a lot more beautiful on URLs.
Efficiency problems: Most of the Portal traffic is large. The loading efficiency of multiple nested and multi-user controls similar to DNN is not optimistic, and SharePoint also has similar problems.
The hierarchy of pages. DNN's Portal> Tab> Module or SharePoint Portal> Site> Page> WebPart can better reflect user needs.