通用分页实现及其OO设计探讨(2)

4. jsp页面实现

(转载其它地方)

六、设计探讨
1
.通过提供 queryTotalRows() queryPageList(int startRow, int rowCount) 方法,交由用户具体的去实现,所以能够支持任何数据库。
对于 Ibatis 用户可以使用 queryForList() 方法 , 对于用 jdbc 实现也可以有多种方法来支持各种数据库。
Ms sql
可以使用 top 关键字,来获得指定范围的数据
ORACEL
可以使用 rowid 伪列来获得指定范围的数据
具体怎么去读取数据,完全交由用户控制
2.
分页对象与具体的业务对象分离。分页对象如果不能与具体的业务对象分离那么就不可能实现分页对象的重用,不可以实现代码的最大的重用。这不符合 oo 的按职责来设计对象的原则。
3. ViewPageHelper
帮助类的使用有两个好处,统一为分页代码所需的字符参数进行定义,便于 contrller jsp 页面代码的维护。第二便于代码重用,减少在 contrller 中的 if 分支句语。如果不使用帮助类,则在每个 controller 中都会产生大量相同的代码。
4. final
关键字的使用, protected final void doInit() 用于分页对象的实始化,它读取并设置总记录数,计算总页数,默认为第一页等。为什么不在构造函数中来做它呢?如果在构造函数来做它,子类就不可以扩展了。像这样的初始化方法的位置应该由扩展类来灵活控制。声明为 protected 是不让它由外部对象来进行访问,但是子类又可以进行调用。声明为 final 是为了子类不能重写它,如果子类重写不当就会造成分页对象的执行逻辑错误。但是如果子类又想扩展它怎么办?子类重写 protected void onInit() 方法就可以了。这样就能保证父类的逻辑,又能够让子类进行扩展。
5.
异常处理的思考, queryTotalRows() queryPageList 方法都是要求由子类实现的抽象类,这两个类的特点都是可能会调用业务对象去实现相应的功能,业务对象可能会访问业务数据库等,可能会抛出任何 Exception ,但是分页对象类去调用 queryTotalRows() queryPageList 的方法是不应该对这些 Exception 进行任何处理的,如果进行 try…catch 那么就会隐藏了异常的细节,这是十分可怕的。如果这些方法抛出异常,分页对象应该是不能处理的,不能处理的异常应该封装为运行时异常,所以就有了下面的实现
java 代码
  1. private List pageList(int startRow, int rowCount) throws ApplicationRuntimeException{   
  2. try{   
  3. return queryPageList(startRow, rowCount);   
  4. }catch(Exception ex){   
  5. throw new ApplicationRuntimeException(ex);   
  6. }   
  7. }   
  8.   
  9. private int totalRows() throws ApplicationRuntimeException{   
  10. try{   
  11. return queryTotalRows();   
  12. }   
  13. catch(Exception ex){   
  14. throw new ApplicationRuntimeException(ex);   
  15. }   
  16. }   

分页对象内部调用 pageList totalRows 方法,这样就很好的解决了异常的问题,把异常交由外部调用者去决定是否处理,而不是强制调用者去处理。

5.
模板方法模式的使用,这是一个典型的模板方法模式的运用。在父类实现关键的算法代码,实现分页对象的处理逻辑,而把某些会发生改变的方法交由子类去实现,使得子类完全不用去关心父类的实现细节,子类只需要重写两个简单的方法就可以实现父类的功能。这就是模板方法带来的最大好处。模板方法模式在各种开源框架中有着广泛的运用,看看 spring 的源码就知道。子类只需要去实现自己最关心的细节,而父类实现那些不变的逻辑或算法。
6.
针对接口编程,而不是针对类编程。接口可以实现多重继承,而类却不能。接口有比类获得更多的好处,更利于扩展。比如说分页接口,它可以让用户有更多不同的实现,完全不依赖于任何类。只需要为它定制了共同的行为就可以了。在使用委托的时候接口比抽像类更好用。比如在装饰模式的使用中,可能需要实现一个接口,而其中还要有一个本接口的引用。 如果是抽象类,则不可以实现。
7.
通用框架应该具有灵活性,不应该依懒于任何具体的框架。如果通用框架依懒于某一技术细节,某一框架,那么它就有一定的局限性。所以通用分页不应该依懒于 ibatis hibernate spring 的某一特点。更不应该依懒于 sql oralce 某种数据库。
 

你可能感兴趣的:(设计模式,spring,框架,ibatis,OO)