67,549
社区成员
发帖
与我相关
我的任务
分享orm框架中动态查询的思考
一个常见的功能，根据用户名或者性别查找用户
做法有以下几种：
1、自己根据用户名和性别是否为空手动组装jpql。
2、在dao层使用动态查询criteria
3、在controller层或service层使用动态查询criteria
如果使用第一种方式，效率很低，也容易出错。
如果使用第二种方式，service层和dao层都会加入大量的接口，因为每个查询的条件都不一样，所以会产生大量的查询接口
如果使用第三种方式，要在controller或者service中引入dao中的criteria。根据面向接口编程和分层的思想，dao框架的接口和类是不应该出现在service和controller中的。考虑到这种情况，可以自己实现一套criteria，最后在dao层将自己实现的criteria转换成jpa的criteria或者jpql，这样就可以实现解耦。不足是这种做法增加了很多工作量
我们都知道criteria是通过会话管理获得的，service如何能获得criteria呢？ 这里可以使用回调（闭包），定义一个接口，该接口包含一个方法，方法参数包含criteria；然后把这个接口当作service方法的参数，最后由dao调用该接口的方法。可参考spring-data-JPA中Repository的实现。
个人感觉这三种方法都不太理想，不知道大家是怎么做的，有没有其他的方案
做法有以下几种：
1、自己根据用户名和性别是否为空手动组装jpql。
2、在dao层使用动态查询criteria
3、在controller层或service层使用动态查询criteria
如果使用第一种方式，效率很低，也容易出错。
如果使用第二种方式，service层和dao层都会加入大量的接口，因为每个查询的条件都不一样，所以会产生大量的查询接口
如果使用第三种方式，要在controller或者service中引入dao中的criteria。根据面向接口编程和分层的思想，dao框架的接口和类是不应该出现在service和controller中的。考虑到这种情况，可以自己实现一套criteria，最后在dao层将自己实现的criteria转换成jpa的criteria或者jpql，这样就可以实现解耦。不足是这种做法增加了很多工作量
我们都知道criteria是通过会话管理获得的，service如何能获得criteria呢？ 这里可以使用回调（闭包），定义一个接口，该接口包含一个方法，方法参数包含criteria；然后把这个接口当作service方法的参数，最后由dao调用该接口的方法。可参考spring-data-JPA中Repository的实现。
个人感觉这三种方法都不太理想，不知道大家是怎么做的，有没有其他的方案
...全文
请发表友善的回复…
发表回复
bcsflilong 2016-10-21
- 打赏
- 举报
如果是新增或者编辑方法呢？ controller如何保证事务？[/quote]
事务交给框架自己去处理 注意方法的命名统一管理
执笔记忆的空白 2016-10-21
- 打赏
- 举报
如果是新增或者编辑方法呢？ controller如何保证事务？
bcsflilong 2016-10-21
- 打赏
- 举报
说实话 为了解耦 我用了第三种方式，但是dao层有个牛X的父类，编码量并不大。
无非是方法很多，但是归根结底都是父类的增删改查
qq_32100781 2016-10-20
- 打赏
- 举报
sql动态StringBuffer拼接查询，引入泛型，使查询更加通用。
可以参考一下这里的做法
http://bbs.csdn.net/topics/392031855
月明星稀灬 2016-10-19
- 打赏
- 举报
这个问题应该拆分为两个问题吧，一个是效率问题跟 数据库挂钩（优化查询，数据库表优化，使用hibernate持久层3级缓存）
另一个问题是架构模型的分层问题，业务一般在Service做，Action只复杂请求分发，DAO只负责持久层。 各层之间的JAVA方法调用没有效率一说吧。
hersing 2016-10-17
- 打赏
- 举报
如果查询条件不确定，传对象过去不就可以了吗，需要用到哪个查询条件用哪个，使用sql拼接
fengwind1 2016-10-17
- 打赏
- 举报
我表示你没用过hibernate，至少是在实际项目中没用过
liguangwen86 2016-10-12
- 打赏
- 举报
1.理论上用第一种效率也没有多低，处理好了也不会出错。
2.第二种也可以根据用户名或者性别进行criteria，也不会加入大量的接口。
3.第三种感觉就不需要使用了，你在controller或service一样需要判断用户名或者性别
