2017-03-20 21:06
升级到 jfinal 3.0，这个版本已经去掉了对 order by 子句的处理
以前的版本用正则去掉了分页方法中用于查询总记录数 sql 中的 order by 是为了提升性能，因为 select count(*) ... 这类 sql 是否存在 order by 并不影响最终的结果
2017-03-20 21:03
@广州雨人 参考一下这些博文:https://www.oschina.net/search?scope=blog&q=jfinal%20dubbo
2017-03-20 19:33
有了对比，才会在认知上更有深度，spring 由于过于繁琐庞大、过度设计、配置文件满天飞，所以才会出现 spring boot 这个项目给 spring 做简化工作，而 spring boot 中的很多功能 jfinal 早在五年前就有了，例如零配置、java config 这类概念、热加载，减少代码量等等设计目标
spring boot 本质上是在重走 jfinal 五年之前就开始走的路，但是 spring boot 底层仍然基于 spring 这个庞然大物，开发者看到的仅是浮出海面的冰山，而隐藏在海水之下的山体才是更大的麻烦，所以很多 spring boot 用户在开发过程中会不断要去学习 spring 有关的概念
jfinal 是极简设计，学习成本极低，WEB MVC + ORM + Template Engine 所有功能仅有 400K 左右的 jar 包，比 spring 体系要小得多，所以无论大家是否想用 jfinal 开发，掌握 jfinal 都是很容易并且值得的
2017-03-20 19:25
@hmgx jfinal 3.0 已经直接支持该功能，参考一下 jfinal 手册有关 cron4j plugin 这一章节
2017-03-20 19:01
DbPro 的构造是自动的，所以 DbPro.init 这个方法对用户来说是不可见的，正确的构造方法是创建一个 ActiveRecordPlugin 对象，然后启动它，DbPro 自然就被创建好了，后续直接使用即可
如果希望自己动态添加 Config 从而创建 DbPro 对象，正确的流程是将 Config 传给 DbKit.addConfig(config) 方法，然后 DbPro 的创建也是自动的
简单来说 DbPro 对象的管理是动自动化的，所以也就不存在初始化和构造 DbPro 这类问题了
2017-03-20 18:51
@abvcb 如果是非浏览器客户端，而是专用的 http 客户端，确实可以直接在 http 协议中体现 PUT、DELETE 这类请求类型，但这样做其实没什么必要，而在 url 中放入请求类型在语义上表达更为明确，站在 API 的使用者的角度看，更容易理解，可读性也更强
从开发实践的角度来说，在代码中必须去指定某 action 为某请求类型，这也会增加代码量，拉低开发体验。抽象资源用什么请求类型映射至某个 action，要么用约定的方式，要么用注解或配置的方式指令，这都会增加学习成本，但却看不到一点好处
