6
回答
JFinal的ActiveRecord的 两点改进建议
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

@JFinal 你好,在 使用JFinal的过程中,有如下两点改进建议:

1、增加SQL语句动态编译功能。

比如如下的sql


"SELECT * FROM product where comp_code=? and `status`=? ORDER BY create_date DESC"

如果我仅仅传递comp_code的参数时,`status`=? 自动去掉,不用我另外写sql。这样sql尽量做到重用,我之前用的框架是支持的,而且不用像ibatis那样,用if 来判断是否为空。


2、向Record set不存在的列名时,最好是不跑异常,给个警告即可。因为在切换数据源时,有的时候两个数据源列可能并不完全一致。

目前是抛异常的:Unknown column 'tt' in 'field list'

希望JFinal越来越强大

举报
Neoman
发帖于4年前 6回/401阅

以下是问题补充:

  • @Neoman :刚才发现,第一个问题jfinal-ext 有类似实现:com.jfinal.ext.kit.ModelExt.findByColumns(List<String>, List<Object>)。这个实现好处是不用写sql。但仅仅适合单表,根据列来过滤的情况,不暂时不支持函数,定制性不强。 (4年前)
共有6个答案 最后回答: 4年前

这些都是个性化的需求了

--- 共有 1 条评论 ---
Neoman我觉得这个不是定制化啊,有需求共性。ibatis就有实现,不过他的语法过于复杂,我之前用的,用OGNL实现的,语法很简单,jfinal也实现的话,就很完美了,可以说完胜其他框架了。 4年前 回复

我觉得第一个很有必要,在查询的时候经常用,不是所有条件都输入的,第三个就没必要了,没有那个字段肯定要 抛异常才正常

第一个实现可以使用freemark等模版语言来控制。这个我已经实现。

另外的一钟是使用参数别名化:如 select * from tab1 where name=#name# 那么只需要传递一个map 的key为name的值即可。此为sql位置分析 然后对map进行值的定位。 也实现了。

引用来自“龙影”的评论

第一个实现可以使用freemark等模版语言来控制。这个我已经实现。

另外的一钟是使用参数别名化:如 select * from tab1 where name=#name# 那么只需要传递一个map 的key为name的值即可。此为sql位置分析 然后对map进行值的定位。 也实现了。

独乐了不如众乐乐,赶紧上代码

      感谢楼主提出这样有深度的建议。设计是一个不断权衡取舍的过程,面对很多纠结点,必须根据一定的设计主张做出决择,JFinal 设计主张其中有避免问题而非解决问题,另一个是做越多可能错越多,最后 JFinal 是极简设计风格,其实这几点是相辅相成,互相关联的。

    对于第一个建议个人认为还是做为扩展方式存在会更好,让底层保持干净与纯粹,这样更加有利于在此基础之上不断做扩展,就好比linux 内核其中一个很牛B的抽象,她将设备也抽象成文件,对设备的操作就抽象成了对文件的read、write,一个简单且纯粹的抽象为上层提供了无限可能,如果要在read、write内添加额外的功能,那么可能对上层再来伤害或阻碍。

  另外基于避免问题而非解决问题的设计理念,如果实现此功能,当开发者在sql中有 n 个条件,而参数 p > n 个,此时可能是 bug 而导致问题。

   第二个建议 Record set进去的字段如果不存在,那么在执行 sql 的时候会报异常,这个是 jdbc 的行为,jfinal 在上层无从得知,如果要做出处理会很麻烦,也会损失性能,同样也基于上面谈到的设计理念仍然不建议实现。

    感谢楼主对 jfinal 的支持,常来提建议 

引用来自“JFinal”的评论

      感谢楼主提出这样有深度的建议。设计是一个不断权衡取舍的过程,面对很多纠结点,必须根据一定的设计主张做出决择,JFinal 设计主张其中有避免问题而非解决问题,另一个是做越多可能错越多,最后 JFinal 是极简设计风格,其实这几点是相辅相成,互相关联的。

    对于第一个建议个人认为还是做为扩展方式存在会更好,让底层保持干净与纯粹,这样更加有利于在此基础之上不断做扩展,就好比linux 内核其中一个很牛B的抽象,她将设备也抽象成文件,对设备的操作就抽象成了对文件的read、write,一个简单且纯粹的抽象为上层提供了无限可能,如果要在read、write内添加额外的功能,那么可能对上层再来伤害或阻碍。

  另外基于避免问题而非解决问题的设计理念,如果实现此功能,当开发者在sql中有 n 个条件,而参数 p > n 个,此时可能是 bug 而导致问题。

   第二个建议 Record set进去的字段如果不存在,那么在执行 sql 的时候会报异常,这个是 jdbc 的行为,jfinal 在上层无从得知,如果要做出处理会很麻烦,也会损失性能,同样也基于上面谈到的设计理念仍然不建议实现。

    感谢楼主对 jfinal 的支持,常来提建议 

休假回来了?
谢谢回复,你说的设计主张(或者我可以叫设计原则)让我受益匪浅
回到这两个问题:
第一个,当开发者在sql中有 n 个条件,而参数 p > n 个可能出现bug 应该是可以避免的(大不了类似ibatis把语法搞复杂点),2楼兄弟实现的即是我的想法,个人感觉用处蛮大,我先在自己的应用里去实现吧。
第二个问题,我的想法是在执行sql之前就做校验,不会让db去抛异常,不是有TableMapping嘛,可以缓存db元数据信息,在忙我还没精读代码,是大概的想法
--- 共有 1 条评论 ---
JFinal笔误了,是 p < n , p != n 更合适 4年前 回复
顶部