数据库动态查询最佳实现

学习下...

from HrOrganInfo
  where 1=1
  #[and createDate>=? and createDate<=?]
  #[and ORGAN_NO like ?]
  #[and ORGAN_NAME like ?]
  #[and IS_ACTIVE=?]

我想知道你的这段代码 动态查询 判断的依据是什么?
<?>号实际运行值是否有效 即不为null 是这样吗？

我觉得SQL内容本身就是业务的一部分，跟业务代码放在一起不是挺好吗。SQL剥离出来，要看这SQL语句还需要到配置文件中去查找，太麻烦了吧。对SQL语句后续的确会有些变动，但SQL变动之后，涉及的代码一般也都要变化吧。真看不出像IBatis这样的把SQL放在配置文件里面有什么好处，跨数据库？

我已经说过，你这种方式谈不上什么最佳实践，这就是一个利用模板技术和API共同构造出来的一个动态生成SQL的小工具。这种思路不仅不新颖，很早就有人提出来过，并且有各自的实现。

之前也有回复，这种基于模板的思路的问题在于维护起来有一定的成本，找一段逻辑，还要参照一个SQL的配置文件，这在“简化配置”这个大前提下，显然已经有点落伍。所以之前我也说过，所谓的一揽子方案，可以说比你的方案简单的多，但是并不能称之为一个好的方案，因为总会有很多乱七八糟的业务，是方案无法满足的。

我觉得你说我和Quake在走极端，正好相反，我觉得你已经走入了一个极端。觉得自己的方案非常具有独创性，非常牛。我想说，这只是一个工具，没什么好吹嘘的，如果做得好，自己用得爽，自然很好，是不用到处去吹嘘的。

好可怜，又一个寨主被打击了...

在用公司自己封装的Hibernate的时候被SQL高手无情的B4了，也许是我的HQL技术不到位。但是种种所谓的ORM框架在有SQL高手，特别是有精通Oracle高级优化的DBA在的时候，还是老老实实的用SQL语句，不要迷恋HQL等各种糖果...

首先解释一下，这个工具并不是只针对sql，是支持hql的，
而且hql或sql可以这么写
from OrganInfo as t
where 1=1
      #[and t.name like ?]
       and t.enable=?
就是说#[]相当于if，只需在需要判断的地方增加#[];

打击不是一次了，之前第一次发表类似这个东西被评为新手贴，我真搞不懂这些所谓牛人感觉成了坛霸，一点对问题的研究探讨精神都没有，就一句话以前有很多人这么做了，甚至做得更好，动不动撤出几年前就怎么样了!我只想跟大家一起分享，要是有人觉得有更好的其实也可以拿出来更大家分享一下，一起讨论一下！
对于downpour所说的话，我想已经偏离了正常的讨论方式，其实没有必要这样，我想宣传给大家带来我的想法，很明显我的思路和实现要比之前论坛里面的实现更加有创意
（当然我很乐意别人在此基础上提出更好的创意，我也期待能够吸收别人的理念，权且是我抛砖引玉，那个谁说的就不错呀，提出用换行的方式替换#[],当然我觉得还是#[]更直观点），但没有你这样说话的，一种打压式，其实我也是想报个不平，我的东西比你们之前实现的差吗?如果是比之前的好，为什么之前的贴子能评为良好贴，而更优秀的做法却被评为新手贴！

真服了你！什么小工具什么模板？我这个只是一个基础类BaseDAOSupport里面提供的，哪里需要那么复杂的使用,如果用hibernate，只要在hibernate的map xml中增加就可以，使用极其方便，不要动不动落伍了！
我告诉你我这个怎么使用：
1、在配置的hibernate hbm.xml中增加<sql-query>（hql的动态使用我改造了做法，还是用<sql-query中写hql语句，取出hql语句处理完再用hibernate Query查询，当然这都是BaseDAOSupport中所处理的，调用是非常简单的，就在继承类中this.findByJdbcQuery.或this.findByHql）
2、DAO层基类继承自己写的BaseDAOSupport（当然是spring和hibernate集成的）

这样就可以直接用了！烦吗！比你的复杂嘛？再简单我感觉就不要写程序了你DAO少得掉！sql的存放文件你少得掉！
大多数人DAO都继承一个BaseDAOSupport(名字可能不一样)，这些你哪个少得掉?我真服了，脑子里面就把别人想成笨蛋！

论坛上之前的一个做法(2007年的):
<count>select count(o)</count><list>select o </list>  
From User u <city|depName>join u.dep dep</city|depName> where 1=1 <name>and u.name = ?</name><sex>and u.sex=?</sex><age>and u.age=?</age><depName>and dep.name=?</depName><city>and dep.city=?</city><count>group by u.name</count><list>order by u.age</list>
可以将现在的贴出来吗？我向你请教，如何能够更简单.拿这个对比只是有点不平衡，这种做法被评为优良贴，我这个明显比这个好n倍!成了新手贴，你也不要生气，我也不会再回了!

真的不知道我是不是在同一个火星人说话。

这年头，使用hbm.xml的人已经少之又少，为什么？因为不乐意在维护一个entity的同时，再去维护一个繁重的xml。所以出现了annotation，出现了约定大于配置。但是你目前的思路还是要维护配置文件，你可以不在你自定义的配置文件中写你的SQL或者HQL，但是你目前的思路基本上还是处于需要有某处地方来维护你的SQL或者HQL语句，这就带来了很大的维护成本，在我看来，这的确就是一种落伍的思想方式。

你的这个工具，请允许我称之为工具，放在2年前，可能会被评为良好贴或者给别人提供一个很好的思路，但是现在再拿出来，还到处宣称自己有多么多么优秀，是不合适的。我想指出的，只是一个事实，你的东西没有你想象中那么优秀，你的语言过激了。如果你想讨论，可以看看之前很多人的实现方式，然后改进你的方案，别人拿不拿别人的方案出来分享，是别人的自由，你总是质疑别人拿不出比你更好的方案来，你为什么不想一想，别人为什么要拿出他的方案来和你讨论呢？

工具和框架是给人用的，自己用的舒服就成，你可以分享给大家，但是不能强迫大家都说你的东西好。Javaeye的论坛一向没有所谓的高手，不过这里至少还有一些敢于提出批评意见的人，能够给出相对客观的评价。

BTW 如果你的东西真的有你吹嘘的那么好，那么具有独创性。就不会有那么多朋友给你投新手帖了。

讨论就此结束，不再做任何回复。

居然成了新手贴确实太冤枉。我觉得这种想法还是不错的。就算是思想落后了，你举出实际代码反驳就是了。
我认为如果输入参数固定的查询语句，用JPA的预定义语句就可以了，这个想法没有用处。但是参数动态的问题可没有直接的解决办法。一个语句如果参数不定的话，就会出现大量的拼语句或者每种情况一个方法。用楼主提出的方法我觉得可以解决大量人工拼的方法，让软件自动帮我们拼。
用配置文件维护的问题不要上来就认为落后。JPA的预定义语句无论你是在注释还是在配置文件里维护总归都要维护。有人认为预定义语句应该和类本身分开，这样更好维护。原来的hbm.xml是你既要维护代码又要维护配置，所以麻烦，但是现在只需要维护一处，怎么会增加成本呢？

1.做点改善吧#[]应该去，不然把SQL COPY进去的时候 还要去写#[] 够麻烦的
2.只是简单的null判断？如果不支持复杂的判断，那应该努力。
3.对于这样的动态SQL 我的实现。

@Transactional(type = TransactionType.READ_ONLY)
	@FinderByCriteria(entity = WfReq.class,
 restriction = {@Restriction(column = "lockYn", value = "Y", condition = Condition.EQ) },
 orderBy = { @OrderBy(column = "sendDate", isAsc = false) })
	public Page<WfReq> getPageListBySend(@FirstResult int start,
			@MaxResults int limit,
			@SearchModeList List<SearchMode> searchModeList) {
		return null;
	}

无SQL 基于QBC annotation声明查询方式 动态 静态 排序 等等，
searchModeList 传入你所谓的#[]#[]#[]#[] 自动判断。并且判断支持非null以外的其他逻辑判断
我只管仍有可能用到的查询参数，其他不管。