基于hibernate的开源通用查询框架 －－ bba96介绍

新开bba96圈子 http://bba96.group.iteye.com/

bba96 框架当前版本 2.2，包含：

bba96-core 核心框架，封装Hibernate Criteria，提供方便的查询以及分页支持，查询参数

bba96-struts 基于Struts2的开发框架，依赖core，提供便捷的CRUD以（分页支持），通过设置form的参数就可以实现复杂的分页查询

bba96-security 安全框架，依赖core，借助core query的简捷实现数据权限（未更新）

项目主页：http://bba96.dev.java.net
bba96 下载：https://bba96.dev.java.net/servlets/ProjectDocumentList?folderID=7768&expandFolder=7768&folderID=7768

或者在圈子里下载： http://bba96.group.iteye.com/group/share

如何使用bba96

1. bba96-core查询例子(未完)

对象关系如上图 Teacher-Group, Group-Student, Student-Exercise分别是one-to-many关系，Teacher-Student 则是many-to-many的关系

 java代码显示有问题，还是上图吧

优势在于
1. 分页信息的支持（自动count相应条件的total count）
2. 查询字段简化，不用关心关联信息，包括Projections中的order, groupby都可以用
对exercise的查询，伪码如 where student:s.group:g.level = 3 and student:s.teacher:t.name = 'wang' order by stduent:s.name 这里面有很多个关联，跟hql/sql相比，bba96 query 更面向对象，你只需要关心业务逻辑
3. 统一的查询入口，包括统一的查询参数结构，全面hql/sql的parse还是比较困难的，而bba96的query结构比较简单(复杂的都封装起来了)，你可以运行期重构query，会用aop的同学应该有很多想像空间，例如数据权限

注：2.3.0版本已加入安全框架（2007-10）

通用查询框架的通用性体现在什么地方？
查询能达到什么程度？
这种框架和直接写hql，sql相比的优势是什么？

呵呵，比我的Struts还被人批评，我好开心啊，怎么来说我的struts已经被我重写了80++%，可以不写任何配置文件呢，对于熟悉我的规则的人，还是可以提高大大的提高效率的

这不是批评，是问个明白，最多是个质疑。

优势在于
1. 分页信息的支持（自动count相应条件的total count）
2. 查询字段简化，不用关心关联信息，包括Projections中的order, groupby都可以用
对exercise的查询，伪码如 where student:s.group:g.level = 3  and student:s.teacher:t.name = 'wang' order by stduent:s.name 这里面有很多个关联，跟hql/sql相比，bba96 query 更面向对象，你只需要关心业务逻辑
3. 统一的查询入口，包括统一的查询参数结构，全面hql/sql的parse还是比较困难的，而bba96的query结构比较简单(复杂的都封装起来了)，你可以运行期重构query，会用aop的同学应该有很多想像空间，例如数据权限

我感觉，除了分页是通用的没什么是通用的。

查询字段简化：如何简化了呢?，用hql不是一样实现么？我直接写一个自己想要的hql，何必配置一个查询模版。

统一的查询入口：为什么要统一的查询入口，配个hql给分页程序就行了，自己想写成什么样就用什么样，想运行期改成什么样都没问题。

主要问题，要查询就查询，为什么要配模版查询，如果为了分页显示，直接配置一个对应hql的显示模版就行了。hql和显示模版要对应在一起，但何必要一起生成出来，直接写不好么？

首先不知道你所说的模板是什么

关于分页，如果写hql，如果要分页肯定还要再写一个计算totalcount，那么你就需要维护两个hql

字段简化的思想源于面向对象的思想，例如我要查询所有 3年级且属于jack老师的同学的测验成绩，而且按照同学的名称排序，那么自然的想法就是我要查exercise，要按照exercise.student.name来排序，而且要求exercise.student.group.level = 3, 还要求exercise.student.teacher.name = 'jack'，对么，为什么我还需要关心哪里join呢？bba96的query就是要实现这个方向，但是为什么还要加(冒号:别名)呢，因为现实中sql连接表是需要一个别名，逻辑上也需要用一个来绑定多个联接时的一致性（当然可以做到默认自动用同一别名）

在深入一点的应用，假设有一个限制条件，这个成绩不是每个人都能查的，只有group.publish＝1，或者查询者就是jack才能查，那么现在就有两种做法，一是为每个查询条件都一个限定，为每个查询条件，如exercise.student.group.level <3，或者score > 60等等，如果查询条件还要变化，那就要维护n*m个条件，另一个方法就是分离查询条件与限制条件，那么只要维护n+m个条件，有些同学会说acegi可以啊，没错，不过你考虑过acegi的实现了吗？据我所知acegi应该是全部查询出来再去过滤，小应用没关系，稍大点的应用还不如维护n*m个条件呢
好，现在分离查询条件与限制条件了，但如果时hql/sql，你能方便的组合查询条件与限制条件么？哪里放join，哪里放别名，有的好搞了，而且这不是业务需要关心的，业务只需要关心那些属性的限制，才不管这些属性需不需要join，用bba96就简单一点点了，just a property limit，当然变成sql时会自动产生合适的join。

模版：我个人认为查询条件范围，别名的设定这种方式为模版。

写两个hql没有必要，写一个在用一个util方法生成totalcount的hql就可以了。相信你也是这么做的。

关心在哪里join这是hibernate可以做到的。可事实是，在用的过程中你是知道对象之间关系的，等同于用之前就知道如何join了，不然查询条件范围也没有办法写出来。

为每个查询条件作限定，这句话不明白，为什么会有n*m这个规模。

acegi把数据拿出来作过滤只是一些功能权限方面的，在数据访问上这样处理 我也无语。

hql/sql都好，为什么要方便的组合查询条件，限制条件可以拼接出来，但也不能想怎么拼就怎么拼吧，别的条件有必要变化么？

业务不关心属性限制，不关心join，这个我很感兴趣，做业务逻辑会不关心底层的业务模型么？。

自动产生合适的join，请说得详细些。

n个查询条件 m个限定条件, 那就有n*m种组合

有没有必要那是业务的事情，做框架当然是尽量实现功能最大化

面向对象，只关心属性，而且重构查询也好理解，hql/sql重构起来就麻烦多了，如可能只是变动两个属性，或者是order by，或是加一个sum，但是所改变的属性，或者orderby,sum都是二级属性或三级属性，用sql/hql你就不得不考虑如何join，虽然不难，其实是非常别扭的，而且每一次维护都要脑子转到数据库的思维绕一圈，为什么不直接维护属性呢？

自动产生join就是bba96在背后把你的面向对象的思维转成关系数据库的思维，例如student.teacher:a.name就会自动 student inner join teacher as a，我这里定义了
:就是inner join
[:就是left join
[:]就是full join
而且，无论是group by ?, order by ?, sum(?) count(?)....这里的?都可以写成A.B:b.C:c.D这样的形式

问一下，CVS的用户名密码不公开？那怎么开源的？只能去下载包？找了半天没找到用户密码