购物的订单。
有几个查询时需要用到的属性:
* 状态:取消、等待、已送货、失败、成功完成
*/
private int status;
/** */ /**
* 标志:已注册用户下的订单,非注册用户所下订单
*/
private int flag;
/** */ /**
* 订单开始时间
*/
private Timestamp startTime;
/** */ /**
* 状态更新时间时间
*/
private Timestamp updateTime;
/** */ /**
* 处理该订单的管理员ID
*/
private int adminID;
对于每一个属性,查询模块必须提供两类查询: 1、按指定属性值查询;2、或者不按指定属性值查询。
比如对状态属性status,则必须提供两类查询:1、指定属性的状态值,比如为等待状态,则查询所有处于等待状态的订单;2、不指定该属性值,此时需查询所有状态的订单。
前阵子实现的方法非常的傻。在Hibernate层就按照某个确定的属性值开始查询。
比如说,下面是按餐馆角色,按指定状态来查询的几个函数。
/** */ /**
* 按餐馆查询所有订单
* restaurantID 餐馆ID
*/
public NMisQueryDataSet getRestaurantOrderList( int restaurantID, int currentPage)
... {...}
/** */ /**
* 按餐馆查询已完成的订单
* restaurantID 餐馆ID
*/
public NMisQueryDataSet getRestaurantFinishedOrderList( int restaurantID, int currentPage)
... {...}
/** */ /**
* 按餐馆查询正在等待中的订单
* restaurantID 餐馆ID
*/
public NMisQueryDataSet getRestaurantWaitingOrderList( int restaurantID, int currentPage)
... {.....}
/** */ /**
* 按餐馆查询已取消的订单
* restaurantID 餐馆ID
*/
public NMisQueryDataSet getRestaurantCancelledOrderList( int restaurantID, int currentPage)
... {...}
为每个角色,每个状态都提供一个确定的方法进行查询。
第一,这个实现方法完全能够满足功能需求;
第二,这个实现方法可读性较好;需要查询社么数据,一目了然;
但这个方法傻的原因在于:
1、方法数量非常非常的多
比如说,上面这个东西,五个角色,四个状态,就必须提供(5+1)*(4+1)=30个方法来实现两个属性的查询功能;若属性达到五个,那么这个方法数量就让人无法接受了;方法数量多了以后,代码编写测试、工作量均大大增加。
2、代码可扩充性非常的差
比如,现在已经实现了角色,与状态两个属性的查询功能,但现在状态属性需要增加一个状态,那么就必须重新为这个状态编写代码,并进行测试。而实际上,增加一个状态,一点也没有影响整个系统的体系结构,因此而增加大量代码,觉得不甚合理。增加查询属性时也有相同的问题。
现在实现的方法略有改进。
比如按订单状态status与开始时间startTime两个属性进行查询。指定订单状态或者不指定订单状态,指定开始时间或者不指定开始时间。结合起来就是四个函数了,如下:
* 分页查询某段时间内的所有订单
* 指定 时间段、页数
*/
public NMisQueryDataSet queryOrders(String startDate,String endDate, int currentPage)
... {...}
/** */ /**
* 按类型查询 分页查询某段时间内的处于指定状态的订单, 指定时间段、订单状态、页数, 不限用户角色
*/
public NMisQueryDataSet queryOrders( int orderStatus,String startDate,String endDate, int currentPage)
... {...}
/** */ /**
* 分页查询所有订单, 指定页数, 用户不限, 订单类型不限, 时间不限
*/
public NMisQueryDataSet queryOrders( int currentPage)
... {...}
/** */ /**
* 按类型查询 分页查询处于指定状态的订单, 指定订单状态、页数 不限用户, 不限时间段
*/
public NMisQueryDataSet queryOrders( int orderStatus, int currentPage)
... {...}
这个方法所产生的方法比刚才方法大大减少。如果查询属性为cnt个,那么所需要的方法数量为2的cnt次方。五个属性查询需要32个方法。
分析一下:
1、属性较少时方法数量较少
2、属性状态数量增加时,不需要修改代码(比如订单状态新增了两个状态,不需要修改代码)
3、增加一个属性,方法数量翻倍
4、需要在每个方法前增加参数的有效性校验
今天请教了一下石长老。
比较好的方法应该是,将所需要的 属性名,对应属性值压入map
在Hibernate层根据map参数动态构建HQL查询
晚了,明天接着写