文章回顾：
1：
秋色园QBlog技术原理解析：开篇：整体认识(一) --介绍整体文件夹和文件的作用
2：
秋色园QBlog技术原理解析：认识整站处理流程(二) --介绍秋色园业务处理流程
3：
秋色园QBlog技术原理解析：UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL
4:
秋色园QBlog技术原理解析：UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序
本节，将为大伙介绍如何设计一个页面的基类，同时为你解析秋色园QBlog的基类设计方案。
一：传统WebForm页面Page基类
传统的页面基类，基本继承自System.Web.UI.Page，如：
///
/// 共用页面基类
///
public class PageBase : 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 隐藏字段的字符串。
[EditorBrowsable(1)]
public const string postEventSourceID = "__EVENTTARGET";
{
// 摘要:
// 一个定义呈现的页中的 EVENTARGUMENT 隐藏字段的字符串。
[EditorBrowsable(1)]
public const string postEventArgumentID = "__EVENTARGUMENT";
//
// 摘要:
// 一个定义呈现的页中的 EVENTTARGET 隐藏字段的字符串。
[EditorBrowsable(1)]
public const string postEventSourceID = "__EVENTTARGET";
// 摘要:
// 初始化 System.Web.UI.Page 类的新实例。
public Page();
// 初始化 System.Web.UI.Page 类的新实例。
public Page();
//省略N行...
}
简说：
为了实现和丰富的服务端控件打交道，继承了TemplateControl这个丰富的控件基类，同时引入的ViewState。方便的同时，也被世人所鄙视，甚至把网站运行慢的原因，都推到ViewState身上。
保守估计也许可能应该或许有部分人群，使用mvc的原因，仅为mvc没viewstate而已，和干净点的html生成
举个小例子：
没有ViewState的，不一定是mvc，可能正如你这样处理：
1：输出前截断输出，对html进行替换处理后，再输出干净的html
2：利用1的方法，把输出的html保存成文件
3：请求中可以缓存html或直接请求html
秋色园不是mvc，何以生成的html没有ViewState，输出前替换了ViewState?答案：No。
二：秋色园之基类设计
秋色园的基类设计，仅是退一步而已，和System.Web.UI.Page一样，继承自：IHttpHandler。
如：
public abstract class HttpCustom : IHttpHandler
{}
{}
以下内容：
将接第三节URL重定向到Default.aspx的示例继续补充，给大伙解析秋色园基类的设计：
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，说明要自己处理,后节待续。
总结：
本节就到这里结束了，从本节中看出，秋色园QBlog(http://www.cyqdata.com/)在设计中，抛弃了传统的Page及它所有的用户控件，开创了自己的生命周期。
然而，当Asp.net没有aspx、ascx之后，秋色园如何开创新的开发流程？页面如何加载与呈现？如何触发事件请求？
下节将为你解析，敬请关注。
最后是本节示例下载：
UrlRewriteModule.rar
UrlRewriteModule.rar
本文转自cyq1162 51CTO博客，原文链接：http://blog.51cto.com/cyq1162/499458
，如需转载请自行联系原作者
