HaloDao之前后台全自动动态多条件查询组件实现(一)

  https://github.com/VonChange/haloDao-Hibernate3

  同为程序猿的我们,相信你也厌倦了根据不同条件动态生成hql或者sql方式的代码逻辑的编写.大片大片的逻辑代码,光看着就已经头痛!
  而halodao主要特性就是为了解决这个头痛麻烦的问题,并且实现方式可以说是极其的简单暴力!并且我相信有许多人曾经也按这个原理实现过,只不过因为其简单而未深思.那么她是咋实现的?她有何优点?为啥不是在重复造轮子?
  那么要知道他的优点,首先要有比较的标准,也可以说是设计原则.下面是我的原则.

最最最极致的懒: 这懒不是复制黏贴,而是比她更高一层次的一个境界—连这两动作,都懒得做.

no think, only use: 尽可能少的思考,少的记忆.只要傻瓜般的使用,这同时也是懒的表现.

不为万分之一需求而实现,而是要寻求曲线救国方式.

简单不过度设计.

  先来看看现在的我们解决该问题的方案,并看看他们的不足之处:

最原始的的手动sql拼接和存储过程拼接:先不说程序猿水平的不同,代码也各异,代码烂不说,维护性更差,这是最差解决方案.

mybatis的动态sql:将逻辑代码放到了xml中,维护性高,代码规范,但是单不说其为了规范,略显复杂的xml编写,大片的逻辑代码写在xml,不光复制黏贴累,看代码也特别累.这违背了极致懒人原则.

基于hibernate的criteria的条件拼接:使用面向对象方式实现,优雅高大上,并且强大到可以拼接复杂查询.但对于绝大数人来说,基本也就能记住他基本查询,复杂的很难记住,当然可以查api.但就这功夫,不如直接写hql或者sql来的简单暴力,毕竟现如今,大多程序猿们只是为了完成任务而敲代码罢了,管她个是否优雅.她违背了简单不过度设计,比较之后我的实现,她真心是设计过度了.

  上面方式比较成熟,但对于极致懒人的需求,我希望前台传参并自动拼接成hql或者sql进行查询,也就是说不仅后台可以自动拼接条件,前台也可以改变拼接条件.
  基于该实现,我曾百度,寻找先例,找出不成熟的实现方式.

基于HIBERNATE的全自动查询框架
实现方式是使用criteria,但criteria实现方式便是拼接hql,这样暂不说从前台传的值繁琐,封装成criteria,岂不是非得通过一个中介收费吗?

锐道的Dorado7基于hibernate的实现动态条件拼接的实现:Dorado7高级查询条件构造器和Dorado7 Hibernate Addon.

他们做法和第一个相似,不够在dorado世界里算是成熟的了.而且我的最初版本是在dorado中的hibernate下做的,保留了她的Page对象实体写法和她基于spingside的hibernate的baseDao写法.

理想中的SQL语句条件拼接方式
基本想法和我一样,但不够成熟,实现方式不够灵活.

  说了这么多,那么我是怎么做的?
  不难发现前台有许多需求是这样的,前台有几个输入框,如果未输入,那么就不需要查询.即逻辑判断为,不为Null并且不为空的值进行查询.那么前台如何传条件是个问题.了解但未实践过nosql,他将数据库实现了基于key-value方式,把字段信息含在了key值当中,那么为什么我不可以将字段和条件放到一个key值当中呢?于是便产生了该全自动查询的实现.
  

于是基本查询代码是这样的:

findListByMap(new HaloMap().set("userName_eq","change").set("password_eq","654321").set("email_eq",null));
//为查询用户名为change和密码为654321的结果集.

  而后台并不是所有情况是空值不查询,那么你咋任性(RX)的查Null值或者空值呢?

findListByMap(new     HaloMap().set("userName_eq","change").set("password_eq","654321").set("email_eq_rx",null));
//查询用户名为change和密码为654321且邮箱为空的结果集.

  那么前台如何传值?

HaloMap parameter=  RequestUtils.getHaloMap(request);
List<User> users = userService.findListByMap(parameter);
/**前台传值:***.do?userName_eq=change&password_eq=654321&a=3即可,而普通a值是不会被识别查询的.
*/

  这种方式,正是理想中的SQL语句条件拼接方式博文的实现,方式略有不同,并且有进一步深入挖掘.但奇怪的是为何没人继续像我这样继续挖掘,我想大概是因为:

1.太过简单,毕竟我现在实现该功能的核心代码不到700行.简单的代码,羞于见人,怎能彰显自己高深莫测的功力!

2.没有继续往下思考,只是停留在简单的拼接而已,认为最多也就这样了,未考虑继续深挖.

  那么问题来了,挖掘机技术哪家强,让我先秀秀我的挖掘技术. 毕竟家乡离蓝翔技校可很近,相信你不会令你失望.(>-<)…..

 下篇介绍她的其它基本使用方法.