项目中求满足某一条件记录数是这样来的: super.getHibernateTemplate().findByCriteria(d).size(). 有些怪. 由于对接口编程与hibernate也多少有些了解,以学习的心态首先想到的是,可能hibernate方法findByCriteria的是一List 的非ArrayList实现类,也就是hibernate自身的一个特定功能的list实现类, 而再在调用size方法时,那个实现类实际上是执行了类似count(*)那样的SQL.
有了这样的假想后, 心里老放着也不是个事, 验证下吧. 于是在IDE里设置断点,调用.
出现了如下图所示的情况:
findByCriteria方法返回的results不是什么高级特定功能的list实现类, 也就是平常的ArrayList! 这还了得!从图中也能到, 返回值的size是3008! 下面的值能看到一个一个的Node实例. 这样也就是说, findByCriteria后再size的策略就是把所有满足条件的所有数据库记录转为java对象加载到JVM内存中. 费了这么大的事,又占了这么多的内存空间,就为了看这些记录的个数!
顺着上面的思路, 再有些夸张地打个比方: 国家为了搞人口普查,也想不到什么好的办法(或者说领导由于某些原因压根就没想),于是一拍脑袋,让全国的人来下数数不就得了. 于是间,火车、汽车、飞机、船等交通工具都塞满了人,他们有一个目的地--首都,也为了一个目标,让国家有关部门数一数人数..... 数完了, 那你们还回去干手里的活吧.
有些搞笑了.
凡事都是有些它存在的原因的,顺着这个想法下来: 这种方法有什么好处? 现在能想到的一个就是,findByCriteria后再size的策略提供了一种统一的方法.这样就可以写到父类里,供子类孙类调用,也就是说在代码实现上有优势.
那有没有可能以效率高的运行方式--也就是很容易想到的count(*)--来做到代码上比较通用的实现呢? 抛砖引玉,希望能得到大家的指点.