没想到下午发的《【自然框架】 页面里的父类——把共用的东东都交给父类，让子类专注于其他。 》启发了热烈讨论，还以为又是一大堆的口水回复呢。看到大家的热烈讨论我很高兴，这才是我希望的讨论环境，无论是支持的还是反对的，我都非常感谢。对我的帮助是很大的，让我知道了哪些是大家可以接受的，哪些是不对的。比闭门造车，一个人写代码好多了。我觉得博客园是一片净土，感谢dudu为我们提供了一个讨论的环境！谢谢dudu，谢谢大家的帮忙！

      写完了才发现，忘记写需求了，就是为什么要这么设计的原因。在这里补上。

      自然框架里的页面分为几类：登录页面、不用验证权限的页面（但是要登录）、数据列表页面、表单页面、删除页面、其他页面（比如统计报表等）。
      
      1、登录页面，还没有登录呢，当然是不能判断是不是登录了，只需要实现验证用户名、密码是否匹配，当然了，并不是一定要他自己实现，也可以调用其他的类来实现。

      2、不用验证权限的页面，比如树状功能菜单，上面的放软件名称的那个页面。恩，我是采用frame的方式的，所有有这两个页面。这两个页面是即不需要判断登录用户是否有权限访问，也没有URL参数。但是要确保登录后才能访问。

      3、数据列表页面，必须登录，必须验证是否有权限访问。URL参数有FunctionID（功能节点ID）。也可能会传递DataID（作为外键处理），DepartmentID（部门ID）。同一类页面的控件的属性赋值也有相同的地方。

      4、表单页面，必须登录，必须验证是否有权限访问，还要验证登录人是否可以访问DataID代表的记录。URL参数有FunctionID（功能节点ID），ButtonID（功能按钮ID），DataID（记录ID），有时候会传递ForeignID（外键ID），DepartmentID（部门ID）。同一类页面的控件的属性赋值也有相同的地方。


      5、删除数据的页面，必须登录，必须验证是否有权限访问，还要验证登录人是否可以访问DataID代表的记录。URL参数有FunctionID（功能节点ID），DataID（记录ID）。


      有些功能是多个页面共有的、相同的，有些是一类页面有的，那么大家会怎么设计呢？我的设计方案就是上一篇说的，

BasePage 对应 登录页面，
PagePermission 对应 不用验证权限的页面，这里验证是否登录，除了登录页面都是需要的。
PageURL 定义参数，并且进行验证，

BasePageList 对应 数据列表页面，处理列表专有的需求。
BasePageForm 对应 表单页面，处理表单专有的需求。
BasePageDelete 对应删除数据的页面，处理删除数据专有的需求。

看了回复后的思考：
1、看了大家的回复，我也觉得把权限验证的函数放在PagePermission不太适合，所以我想把它放在另一个地方——UserInfo，就是记录登录人信息的一个类。

2、另外对于“组合”，我还是比较迷糊，一开始以为是组合模式，下班后看了看书，感觉又不是。那么大家说的组合又是什么呢？学习面向对象的时间不是太长，这方面还是很欠缺的。

3、继承的层数，这个好办，登录页面就是一个页，可以直接继承System.Web.UI.Page ，这样就少了一层。树状功能节点页面，这类的也就三个，也可以直接继承System.Web.UI.Page，这样继承的层数不就少了吗。或者给这三个页面单独做一个父类。

不过有必要为了减少继承的层数而特意这么做吗？或者说，在继承的时候，我们还要数一数，不能超过3。

问：为什么要这么做？答：因为书上说......
这个也太死板了吧。呵呵。

4、组合优于继承，那么是不是说继承就没有用了，都用组合吧。不是这样的吧。我觉得继承的一个优点就是可以“被动”执行，就是说不用在子类里面现象的调用函数，而是由父类默默的去做了。当然这么做也有个缺点，那就是如果不看看父类的代码（或者看说明文档）的话，那么就不知道父类到底做了什么。

欢迎大家继续拍板砖，呵呵，这样的讨论氛围我还是很喜欢的。大家觉得呢？

      
ps：不是道大家是不是有空？如果有空的话，是不是可以根据这个需求来设计一下呢？

==========================
= 希望我的想法，能够给您带来一点帮助！ =
= 大家一起研究、讨论，共同提高、发财！ =
==========================

• 框架