【自然框架】 页面里的父类——把共用的东东都交给父类，让子类专注于其他。
===================
以前发过两篇关于页面基类的文章，由于当时对于聚合、组合、桥接模式等不清楚，所以说的也是比较乱，这些日子又学习了一下程杰的《大话设计模式》，又有不少收获。现在我们再来重新分析一下。
先说需求：
1、 对于MIS来说，大多数页面都需要验证一下访问者是否已经登录，是否有权限访问页面，是否有权限操作指定的记录。
2、 对于自然框架来说，大多数页面都需要FunctionID、DataID等，这些值主要是通过URL传递过来的，也有通过其他方式设置的。那么就要求如果是URL传递过来的，那么就要验证是否正确，以免注入攻击。同时还可以兼容其他的设置方式。
3、 列表页面、表单页面等对于参数的验证方式不尽相同。列表页面、表单页面都有各自的处理过程。
4、 大多数页面都需要和数据库打交道。需要一个统一的操作数据库的方式，要支持事务。
5、 还有一些各个页面都要处理的事情，也应该“提炼”出来。
需求分析：
URL的处理是和页面关系最近的，而且不同的页面类型还需要不同的处理方式，那么这个就交给页面基类，通过多态的特性来处理不同的情况。
验证是否登录、是否有权限，这个和当前登录人关系密切，那么就写一个类来单独处理，这个类就是“登录人信息管理”，交给他来负责。
和数据库打交道那就交给“数据访问函数库”好了，可以把这个实例传递给处理业务逻辑的函数，也可以传递给表单控件，这样事务就可以全部联系起来了。
用Visio画了一个UML图，恩，很晕。好像应该没有画错。
这回比较清晰了吧。页面基类负责FunctionID等参数的获取和验证，验证函数定义为virtual的，以方便子类根据情况来修改。页面基类有派生出了三个子类，分别是列表页面、表单页面、删除页面。在基类里定义的FunctionID，并且通过了验证，那么在子类里面就可以放心使用了。同时子类还可以通过override来直接设置FunctionID。
页面基类里定义了两个实例，一个是数据访问函数库的实例，一个是当前登录人信息的实例。前者负责和数据库打交道，后者负责验证是否登录，是否有权限访问。职责分离出去，各做各的互不干扰，页面里调用就可以了，不需要关心具体的实现。
这个可以叫做桥接模式吧？
还有一个没弄明白的就是，页面基类和数据访问的关系，是聚合还是组合，不过想想还是算了，头痛。
还是写一下下载地址：http://www.cnblogs.com/jyk/archive/2009/10/28/1591680.html
Demo的下载地址：http://www.cnblogs.com/jyk/archive/2009/11/02/1594866.html
=======================补充===================
什么是交接模式？引用《大话设计模式》里的定义：
桥接模式（Bridge）：将抽象部分和他的实现部分分离，使他们都可以独立的变化。（P229）
不知道大家有没有看懂这个定义，至少我是没弄懂，呵呵。再引用一段《大话设计模式》的一段解释：（P232）
小菜：“我觉得交接模式所说的‘将抽象部分和他的实现部分分离’，还是不好理解，我的理解就是实现系统有多个角度分类，每一种分类都有可能有变化，那么就把这种多角度分离出来让他们独立变化，减少他们之间的耦合。”
这个就是作者（程杰）的理解吧，这个解释够白话的了，不过我还想说一下我的更加白话的理解，呵呵。大家看看对不对。
我的理解就是：有两套或者多套独立的“多态系统”，他们可以各自独立的变化（继承），互不干扰。然后选择一套系统作为容器，在这个容器里定义其他系统的实例或者借口，通过这种关系（组合/聚合）把两套或者多套系统结合起来，配合工作。组合/聚合就好像一座桥梁一样把这些系统结合在一起，所以就叫做桥接模式了。
就好比我的这个例子里面，页面基类就是一套“多态系统”，他可以派生出列表页面基类、表单页面基类等，把页面基类作为容器，在其内部定义数据访问函数库的实例，定义当前登录人信息的实例。而数据访问函数库还可以自行派生出SqlClient的访问类、OleDb的访问类，他们是独立的“多态系统”互不干扰。页面基类如何变化不需要考虑数据访问的问题，数据访问函数库如何变化也不用考虑有多少种页面。这就是所谓的减少耦合吧。