【自然框架】——页面基类与设计模式（一）桥接模式

 

【自然框架】 页面里的父类—— （补充）

【自然框架】 页面里的父类——把共用的东东都交给父类，让子类专注于其他。

 

===================

 

　　以前发过两篇关于页面基类的文章，由于当时对于聚合、组合、桥接模式等不清楚，所以说的也是比较乱，这些日子又学习了一下程杰的《大话设计模式》，又有不少收获。现在我们再来重新分析一下。

 

先说需求：
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