使SQL/HQL/JDOQL更容易编写与重用(上）

    无论用什么ORM方案，查询语句总还要写的，"如何让它容易写些"怎么也不outdate.
    什么样的SQL最好看好写呢? 我觉得一段有着良好分行与缩进，中间没有太多+号或者java代码这类杂质的就已经是很好的了。

    可实际情况是，当查询复杂时，上面的要求很少达到。

    1.最倒霉的程序员会看到什么呢？他会看到一堆拼接SQL的API， 如Hibernate的Critertal
       或者Team里的天才主力为了对付那些烦人的分号和"And "而写的SQL Builder类。
       但是，对于人这种高智慧生物来讲，理解一段DSL语言要比读懂一组API容易得多（当然，对于机器来说刚好调转），这也就是为什么当初全世界一起设计的是一组SQL语言标准，而不是一套查询API了。
       所以，我觉得API式的方案只在非常机械，同时复杂度又不高的动态环境里才适合使用。

   
       即使没那么倒霉，有些麻烦还是逃不掉......

   2. SQL经过复杂拼接，读程序很难再把握其全貌与来龙去脉
        有时是为了根据用户的输入与选择而动态输入SQL。
        更多时候是为了SQL的重用（鉴于SQL代码比java代码还要难读难改，而且没有refactor工具，SQL达到最大重用，尽量减少duplicate是对日后维护人员的最大恩赐），少不了非常多的SQL拼接。

      有些拼接是几个String变量眼花聊乱的相加，有些还封装到不同函数里。
      这时程序员只有在最后一刻把组装好的sql打印出来并把它重新格式化一遍，才可能是了解它的意义，否则单靠那些字符串变量和函数上的似通非通的注释，除了原作者，其他人好难明白它的意思。

    另外还有两样麻烦事情逃不掉就是：

   3.如果用Prepared statement，?号一多，想对号入座就很困难
      如果有什么修改就更会引发雪崩般的恐怖。如果不用prepared satement，直接在把值写在SQL里，一方面性能上可能对不起用户，另一方面N多+号和双引号也让写的读的人很不爽。

    4.还有就是SQL的对齐缩进换行
    因为Java的String 不支持Mutli-line，连J2SE5.0也做不到这点，(Groovy倒是支持了)，每换一行就要写上一些+号和双引号，如果SQL是一气呵成的倒没什么，如果是要反复修改时，不停维护这些+号和双引号就有点烦了。
   （还有一些更无聊的人，在根本不是瓶颈的地方追求效率，用到stringBuffer.append()，和DB查询相比这根本实在微不足道啊）

    所以，我们无论是用JDBC还是Hibernate，JDO，都可以在上面作一个处理查询语言的小框架（一千几百行就够了），多少消除一点上面提及的不便。

让框架做点事情使SQL/HQL/JDOQL更容易写一些(下）