谈谈IBatis的动态SQL应该改进的架构设计！

上述想法都已经实现了？

之前实现过通过FreeMarker模板配置SQL，还算比较方便，供参考：

<select id=”id” parameterType=”Blog” resultType=”Blog”>  
        SELECT * FROM T  
        WHERE 1 = 1          
        <#if title??>AND title like ${title}</#if>  
</select> 

有这么多经过时间验证的成熟模板语言不用，非得自己去搞一套，也只好无语～
当初就是看iBatis在语言功能上太弱了，所以才自己写了一个dynamicSQL。
当然还有取出拼接后的sql和statement，在程序中更能自由的控制，很多时候这种控制是必要的。

哥们有个<if test="@Ognl@isNotEmpty(cmpEndDate)">  判断，为空那个字段就不生成sql语句

用外部的模板语言也会有一些问题。像：每次都要解析，当控制参数一样时，不容易做到缓存解析好的sql语句以及命名参数对应等等。每次都要重新解析出sql，重新对应参数，重新绑定映射关系等。

我说的就是这个判断啊 = = 你一个更新语句把所有的字段都加了这个判断 如果不是所有字段都是必须录入项  我本意想更新某个值为空 这个sql不是做不到了。。。

呵呵～ 你可以不用参数来动态拼接，可以在里面写固定的SQL。
该用什么要根据具体情况来分析

业务没有这方面的需求所以才这样的

那这个帖子讨论的基础就没啦。。。呵呵。。。

人是活的，如果你非要参数化后SQL缓存，你可以从参数的hash着手

能否详细解释下hash如何做。

我的表述是这样的。例如：


对于if这些语句的判断，可能造成返回的sql在参数上不一样，如可能返回：

xxxxx state = #{state}

也可能返回：

xxxxx state = #{state} AND title like #{author.name}

只有模板解析程序才知道那些条件性参数使用了，从而知道是否可以缓存。例如对于 xxxxx state = #{state} 我们知道触发了条件1，对于 xxxxx state = #{state} AND title like #{author.name} 触发了条件1和3.

如果以后的查询条件，解析出应该触发1和3，就可以直接返回解析好的。

每次传入的参数值可以不一样，但只要对模板解析的触发条件一样，就可以缓存解析结果。

如果使用freemarker或者velocity之类的，就很难感知或确定触发条件的一致性，进而使用缓存结果。如果在意性能，这些性能改进还是值得的。对于操作频繁的系统，尤其是网友参与的外网系统，每个sql每次都解析1遍模板也是挺费时的。