秋色園QBlog技術原了解析：Module之頁面基類設計(五)

文章回顧：

一：傳統webform頁面page基類

傳統的頁面基類，基本繼承自system.web.ui.page，如：

///

/// 共用頁面基類

public class pagebase : system.web.ui.page

{}

如此繼承的原因？

1：為了處理某些共同邏輯、減化代碼、統一處理某些事情所需。

2：基于開發中，要用到很多使用者控件、viewstate等，享受豐富的服務端控件帶來的開發優勢，提高開發效率。

3：早已習慣webform開發，雖然最近mvc流行。

我在一些内部系統或站點管理背景上，也經常使用，如我用它來處理以下内容：

1：使用者權限

2：常見方法封裝，包括服務端方法、腳本方法。

3：清單控件repeater/datalist/gridview的進一步控制：如：光棒效果[就是移動時行的高亮顯示]、列頭翻譯，列的隐藏控制等。

4:其它......

再簡單看一下system.web.ui.page，發現如下的繼承：

public class page : templatecontrol, ihttphandler

{

// 摘要:

// 一個定義呈現的頁中的 eventargument 隐藏字段的字元串。

[editorbrowsable(1)]

public const string posteventargumentid = "__eventargument";

//

// 一個定義呈現的頁中的 eventtarget 隐藏字段的字元串。

public const string posteventsourceid = "__eventtarget";

// 初始化 system.web.ui.page 類的新執行個體。

public page();

//省略n行...

}

簡說：

為了實作和豐富的服務端控件打交道，繼承了templatecontrol這個豐富的控件基類，同時引入的viewstate。友善的同時，也被世人所鄙視，甚至把網站運作慢的原因，都推到viewstate身上。

保守估計也許可能應該或許有部分人群，使用mvc的原因，僅為mvc沒viewstate而已，和幹淨點的html生成

舉個小例子：

就發電來問：

呀的~沒有viewstate的就是mvc?

沒有viewstate的，不一定是mvc，可能正如你這樣處理：

1：輸出前截斷輸出，對html進行替換處理後，再輸出幹淨的html

2：利用1的方法，把輸出的html儲存成檔案

3：請求中可以緩存html或直接請求html

秋色園不是mvc，何以生成的html沒有viewstate，輸出前替換了viewstate?答案：no。

如：

public abstract class httpcustom : ihttphandler

以下内容：

1：建立類庫，為了自己好找，名字還以urlrewrite開頭了，叫：urlrewritemodule

2：把class1.cs更名為httpcustom，并繼承自ihttphandler，如下圖：

正如上圖你看到的，截圖時類少寫了一個關鍵字：abstract，哈哈~

3：建立自己的頁面生存周期方法，大體如下：

說明：

從上面的示例中，我們建立了屬于自己的頁面生存周期，把那個經常屬于面試題的page的頁面生存周期都仍一邊去。

4：接下來，再做點事，把重點引到ashx處理程式中，并抛棄aspx

4.1：在原來的站點urlrewritedemo中添加對項目urlrewritemodule的引用

4.2：添加default.ashx處理程式，繼承自httpcustom，并重寫page_load方法：

4.3：把urlrewrite庫的重定位，從之前的定位到defaut.aspx改成default.ashx

5：一切就緒，f5運作看效果

再來一張：

經過上面的一折騰：

我們實作了屬于自己的頁面生存周期，并以比較讓人熟悉的page_load方法，分給各個ashx處理程式，當然，基類要做的事情，還有好多，比較好多方法都是private，說明要自己處理,後節待續。

總結：

下節将為你解析，敬請關注。

版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：

http://www.cnblogs.com/cyq1162/archive/2011/02/24/1963621.html