在Asp.net业务系统的开发过程中，为了保证页面风格的一致性以及减少重复代码的编写，我们需要引入基类页的概念，即：定义一个基类页，让所有的页面都继承这个基类，并在该基类页中加入公用的属性和方法。
实际使用时，按照功能页面划分，可以定义多个基类页，如：
class FormBase
class BizFormBase ：FormBase
class ViewFormBase : BizFormBase
class EditFormBase : BizFormBase
class QueryFormBase : FormBase
FormBase：基类页中的根，提供与业务无关的服务，如：URL重写，日志等。
BizFormBase：加入和业务相关的属性，如：该页面的当前业务对象ID等。
ViewFormBase，：EditFormBase：实现具体的查看，编辑功能。
QueryFormBase：实现对通用查询页面的封装。
从面向对象的角度看，基类页与普通的基类，继承类设计其实区别并不大，都要在基类中编写公用的属性方法，并通过虚函数、事件等方式让继承类重写或响应。所不同的是基类页的设计过程受到所在环境的约束。在WinForm环境下，我们可以预先定义好窗体的公用元素，如工具条，默认的表格以及DataSource控件等。而到了Asp.net下的WebForm，则无法实现界面一级的继承，同时加入了状态管理等要求。
为了帮助大家理解，我们以查询基类页的设计过程来分析：
一个最简单的查询页面会包括三部分，多个查询条件文本框，查询按钮，以及表格。同时查询页会和一个数据访问组件关联，当点查询时，会把查询条件转成where语句提交给数据访问组件。
当点击查询按钮时，我们做了以下三件事：
1 获取查询条件
2 提交查询
3 将查询结果绑定到表格
这儿的提交查询和绑定在不同的查询页面都是一样的，于是我们首先把2，3放到基类页中，并提供这样一个方法：void QueryAndBind(IManager manager, string sql);这儿要定义IManager接口，让所有的Manager都实现该接口，这样基类页就无需知道具体的Manager，只要调用IManager.GetDataTable方法,然后绑定表格到即可。
使用基类页后的代码：
1
QueryPeopleForm : QueryFormBase
2OnQueryButtonClick()
3
{
4
string peopleName = txtPeopleName.Text;
5 string peopleAge = txtPeopleAge.Text;
6
sql = string.Format(“Name Like‘%{0}%’and Age = {1}, PeopleName, peopleAge);
7 QueryAndBind(new PeopleManager(), sql);
8
}
把拼Sql的工作放在Query类中做，调用者只要声明查询字段，对应的值，和比较类型即可。
到这一步，我们的基类页已经很好用了，但还有一个小问题，也就是前面说的，在WebForm中无法实现界面级的继承，那么基类页的QueryAndBind方法，将无法知道查询结果要绑定到哪一个表格，这时我们的做法是在基类页中声明DefaultGrid属性，让继承页来告知当前的表格控件。
总的代码可以从附件中下载，大家可以加入断点，看看基类，继承类页的代码执行顺序。
应该说基类的设计相对复杂，但好处是继承页的代码变得清楚了，没有多余重复的代码。
而基类页的设计其实是有技巧的，总结起来有以下几条：
1 首先以最直接的方式写出页面代码
2 提取公用方法和添加辅助类
3 提取事件处理流程到基类页中
4 在基类页中设计需要继承页重载的方法与事件
从设计上来讲，用基类页的方式来统一操作、简化页面代码是一种非常直观的方式，缺点是随着项目的演化，基类页会变得大而全，不容易被新的项目重用，这时我们就可以考虑把其中的一部分功能放到用户控件和自定义组件中来实现，以减少耦合性和提高重用性。