让框架做点事情使SQL/HQL/JDOQL更容易写一些(上)
这篇讨论那个存在于普通SQL/HQL语句 与 JDBC/HIbernate之间的,一千几百行代码量的SQL处理层怎么写。
开源项目里,iBATIS这个以SQL为基础的ORM方案可以参考,另外还有它的新竞争对手ORBroker,后生可畏、后发制人,易用性方面走得更远。
1.针对SQL的换行和对齐,无非就是把它写到XML里面
这样就可以不受Java String不能换行的鸟气了。
这时的问题就是,饱含逻辑的SQL代码被从业务类里面分离出来了,我又不是很喜欢。
还有一个未来的方案是用Groovy来写业务类,然后把它编译成Java类。可爱的Groovy支持
String sql = "select * from foo
where ....."
2.针对N多的?号参数,无非就是使用命名参数
//把sql编译成PreparedStatement, 并对属性赋值
String sql = "select * from dandy where name=:name";
query.setParam("name","gigix");
做得好时,还应该支持内嵌的属性,解决属性同名的问题
String sql = "select * from dandy,pet where dandy.name =:dandy.name and pet.name=:pet.name"
query.setParam("dandy",gigix);
query.setParam("pet",pet);
最后, 还应该支持对象里全部属性的自动绑定,简化书写
//把gigix对象里的age,name属性自动绑定
String sql = "update dandy set age=:age where name=:name "
query.setObjectAsParams(gigix);
3. 解决拼接SQL(1)--优先使用Replace而非拼接SQL, 把SQL的概貌反映出来
String sql = "select * from foo order by {{sortColumn}}";
....//条件判断语句
query.setReplace("sortColumn","code");
在整体的把握上, 要大大优于下面的迷宫阵法
String sql="select * from foo";
...//条件判断
sql+="order by code";
4.解决拼接SQL(2)--把可重用的SQL统一管理
依然是整体把握优于局部拼接的思想
对于可部分重用的SQL,现在的开发人员要不重用,完全Copy Paste,一旦要修改就改得山崩地裂
要不就是把重用和不重用的部分复杂拼贴,又摆一个迷宫阵法出来。
O/R Broker的做法值得参考:
<sql-statement id="getEmployees" result-object="Employee">
SELECT
*
FROM
Employee
<append-statement id-suffix="ById">
WHERE
EmployeeId = :id
</append-statement>
<append-statement id-suffix="BySalaryRange">
WHERE
Salary BETWEEN :lowSalary AND :highSalary
</append-statement>
</sql-statement>
然后你getEmployeesByID 和 getEmployeesBySalaryRange可以返回不同的SQL
5.拼接SQL(3)--Velocity/Freemarker永远都是文本生成的好工具
Web页面生成也好,代码生成也好,Template Engine都被证明比pure java code好得多,否则大家怎么不个个去写Servelet呢,生成SQL当然也不例外。O/R Broker就有这个功能,聪明之处还在于,直接调用Velocity引擎就行了,不花自己一行代码。
<sql-statement id="getEmployee">SELECT EmployeeId,EmployeeName,Salary,FROM Employee#if ($employee.id)WHERE EmployeeId = :employee.id#end</sql-statement>