2017-10-23 11:19
WebSocketController extends Controller
spring 集成 websocket 也需要用Component管理这个webSocketController。jfinal 应该也不例外
2017-10-12 12:44
@社会你钟哥 https://www.activiti.org/userguide/index.html#historyQueryTaskInstance 这个是官网的文档
2017-10-12 12:37
@社会你钟哥 我看了之前写的。其实写得并不好。网上有其它 jfinal 整合 activiti 的案例，当然那些不看也罢，整合无非就是以插件的形式启动 activiti的流程引擎，初始化各种 service. 真正需要理解的是 activiti 的各个 service 的使用。
2017-10-12 10:03
可以以插件的形式添加到 jfinal 中。以前做过，不过现在不会再沿用以后的做法，做过后会发现有更好的做法。不过现在没机会再实践了
2017-09-27 16:23
改。按照想法就是把存储在session中的那代码改成存储在redis中。验证的时候也要去redis拿。key 值当然是当前 session。所以
--- 感觉没必要改成redis。
2017-09-27 11:59
@Lg 如果要写工厂模式的话，那你可以写一个考虑所有 service 的工厂，不然还是用static 变量的形式，否则也只是多添加一个类而已。
业务写在 Model 里不是不行。我刚用 jfinal 的时候就没有把业务写在 model 里，一来是 bean 定义会被破坏，二来是 now Model的时候会产生额外的负担。所以我不建议这样做。你把业务逻辑写在 service 里面吧。这样好点。（个人建议
2017-09-27 11:52
jfinal 直接定义一个类的成员变量的service就可以了吗？
-- 讲讲这个
spring 的注入本质上也是一个分层。计算机世界里遇到一个问题，通常很多都是加入一个新的层次来解决。缓存的概念也是如此。jfinal 没有注入的概念，只有 new。为了保持 service实现类的 单例性。可以通过定义一个 static service 变量来完成，达到同样的单例目的。
2017-09-27 11:49
jfinal 直接定义一个类的成员变量的service就可以了吗？
--- 这句话想表达什么意思?
service 层只是抽取出了一层，不然把所有的业务逻辑写在controller里，将代码全部平面展开，既杂乱又不分层，这又不面向对象，也不利于开发和维护。按照另外的说法，对于后期分布式的展开也是灾难。ssh以前的项目，抽取一个service层道理应该也是如此。再抽取多一个dao层也是为了应付数据库连接的变更（虽然几乎很少遇到需要变更数据表的）。根据项目来拆分层次吧。可能 service 层，dao 层，如果项目需要，进行适当的增加层次我觉得也是可行的。
2017-09-22 10:27
Hibernate 太重了。不过现在 jfinal3.0 有 sql 抽象出来的模板，再加以适当的参数填充。感觉也是很不错的。避免了重要撰写大量重复的sql 语句。以前这部分工作是需要自己手动撰写。
2017-09-22 10:21
对对对。全是 sql 虽然是极薄封装。但是现在代码的可读性与维护性在一定性能条件的损失下是更加重要的。
参考现在众多的 jpa 实现。Hibernate,mybatis等。
