呵呵,高手们都来了,讨论一下OOSQL(SQL类型化)的问题:
DAO的好处究竟在哪里?我也经常用,最好用的应该是强类型化,跟.net的强类型DataSet一样.Coding代码提示,编译期间检查. 代码提示不用说了,提高编程效率.
但是有两个美中不足:
1. 很多查询语句还是需要手工来写,比如Entity和JDO的查询都有自己的语法和限制.iBATIS把它分离到xml里面,其实还是string. string是很容易出错的.
2. 表refactor,还是要check/update这些sql语句.这也是最头痛的问题.
为什么不把SQL也OO呢?SQL也就那些语句,OO起来应该也很简单,这是我的一个设想:
Sql sql = new Sql();
Table1 t1 = new T1();
Table2 t2 = new T2();
t1.setLeftJoin(t1.col1,t2.colA);
sql.setColumns(t1.col1,t2.colB); //表和关系由这里取出
sql.setWhere(Func.Eq(t1.col2,"abc").and(Func.In(t2.colC,new object[]{1,2,3})));
sql.queryModel(Table2.class);
这种OOSQL有几个好处:
1. 几乎没有功能限制.Func只是定义标准实现, 各个数据库可以有自己的扩展Func, 并且覆盖一些非标准语法,比如Func.SysDate
2. 无限数据库支持.每个数据库可以定义自己对SQL的解释
3. 分页机制可以利用数据库自己的特长.比如mysql在解释sql的时候加上limit n,m
4. 对SQL的查询结果由单独模块承担.QueryModel,QueryRowSet,QueryOne,QueryArray,ExecUpdate,execScalar...
5. 非常适合动态构造查询.
OOSQL的效率很可能不高,但是sql一般都是静态的,用singleInstance或者静态变量应该可以对应.
上面where语句的拼写方式还需要检讨,如果Java也支持运算符过载就爽了.不过个人倾向微软的SQL设计器,就是vs.net,access,excel都带的那个用表格来表示查询语句的东西.M$可以把复杂查询抽象成一个简单的表,还是很佩服的,也许OOSQL也可以采用那种方式来简化.
另外,现在对Model的显示,还处于刀耕火种,应该在定义Table类的时候加入Table的描述,字段加入标题,描述,显示长度,校验方式...就象SAP那样齐全,这样利用结果集提供的信息就能自动构造画面/输入绑定检查.无需大量Coding. 这是我的另外一个梦想:全能的数据类型
以上都是个人的胡思乱想,也许已经有实现,如果没有,大家看看怎样,有能力的兄弟给实现一下 :)))