SQL动态封装工具类

我最感兴趣的已经After Where 的部分的处理。我现在的框架里就这个没有处理好。我想现在研究一下，把这个加进去。

但是这个拼装，估计还要造一下，用setparameter形式来处理才行。

    /** 
     * 顺序排序 
     * @param field 
     */  
    public void setOrderByClauseAsc(String field) {  
        this.orderByClause = getFieldName(field) + " ASC";  
    }  
      
    /** 
     * 倒序排序 
     * @param field 
     */  
    public void setOrderByClauseDesc(String field) {  
        this.orderByClause = getFieldName(field) + " DESC";  
    }  

哈哈，是呀，好好的SQL不用，却要多加一层，看的时候你首先得看懂代码，然后再想象SQL是什么样子，建个bufferstring直接append不就行了吗？，这样也直观，简单就是幸福，简单就是快乐！

是挺不错，不实用

严重同意，这种看着别扭，除了问题调试堆栈有多了几行而已！

你这个比DBUtils好在哪里？

服了你们几个“大牛”，没有人喜欢无中生有的搞事，试想用一堆if else封装一个动态sql的情景吧。

jamiesun 说的没错.

"建个bufferstring直接append不就行了吗"

- 这样在每个需要拼接 sql 的地方就都需要拼接, 拼接逻辑重复了,
  并且没有进行更高层次的封装.
- 如果拼接逻辑有bug, 就要在多个地方改动, 别人要看懂你的代码,
  还是要看懂你的拼接逻辑, 并且还要看懂你每处的拼接逻辑, 因为不知道你每处的
  拼接逻辑是否是一样的;
- 把拼接逻辑封装起来, 减少了代码重复, 并且提高了拼接逻辑的可测试性;
- 应用程序内越一致地使用封装起来的sql拼接逻辑, 就越少让人看得头大的处处
  散落的拼接代码.
- 如果拼接逻辑需要根据应用需要的sql复杂性进行演进, 这只会在一处体现在API
  的变动上, API的变动很易于使用 IDE 的 重构功能来进行.

谢谢 jamiesun 提供这样的封装.
我正着手做这样一件事情, 正好用上了.

支持，这些ORM框架的SQL封装思路值得借鉴。

现在已经有很多这种util了吧，忘记叫做什么名字了。

其实用JDBC的时候，拼SQL也是很实惠的，简单明了，安全稳定， 容易检查。 但是不好管理。反正都被封装在DAO这一层。

不过楼主这样一封装，显得就fashion了很多。

ps，一个小问题，最近用substring的时候发现会有memory leak, 如果你要是在这么common的地方用的话，还是注意一点的，不然会有莫名其妙的gc的问题。