2016-11-13 14:37
amazon 的创始人贝索斯小时候的一个经历，造就了他提倡的“善良比聪明更重要”。张小龙上一次演讲提到，他很担心微心占用了大家很多的时间，这极大体现了他的“善良”之心，一般的做产品的人会与此相反，希望自己的产品能最大程度地占用用户的时间，造成的后果是将人们带入了更加碎片化的时代
时间的碎片化对用户来说是非常大的伤害，这个从我上个月停用微信朋友圈，删掉关注的公众号，删掉所有产生内容的 app 后所带来的价值飞越得到了极大的验证
而小程序就是这样的一个理念，平时不打扰用户，用户有需要的时候用完即走，既带来价值，又不对用户造成损害
所以 jfinal.com 社区，目前为止也没搞出什么特别打扰用户的功能，jfinal 希望静静的呆在这里，朋友们有空的时间自己来看看就好
2016-11-13 14:28
@netwild 下个月上 jfinal 2.3 ，确保四年冠，多多关注社区动态，感谢支持社区发展
2016-11-13 13:44
再针对后面具体的问题做个简要回答：
1：Json 无论是转换性能，还是传输体积都是很好的方案，类似于腾迅开放平台、微信公众号这类巨型系统，都是走的 json 以及 xml，不会有问题。json 转换使用 FastJson 确保高性能，阿里巴巴内部都用的这个东东
2：HttpClient 是一个比较老的项目，很久没有关注过它的性能了，可以尝试一些比较轻量级的新的 http 工具包，例如 okhttp，比较下性能，选择最好的
3：http 的开销比 socket 确实是大了点，不过好在开销的消耗集中在每次请求都有三次握手，所以，一定要注意要开启 http 的 keep alive，并用心跳请求保持住长连接，这样可以让 http 建立长连接，不用每次请求都再重新建立连接
2016-11-13 13:39
你的这个架构设计，总体上是极好的，如果性能出现瓶颈，先做集群，将 DB IO Service 与 Controller 这部分多实例部署
如果做了分布式，那么各分布式结点可能需要通信，一般情况下仍然用 http 走 json 就可以，如果是极大的性能要求，可以用 netty 走 socket 通道，我估计你很长时间都用不上，这都是巨型公司才要用的
2016-11-13 13:36
有人这么做过，效果极好，在你现在的架构图上只需要做一点点改动：将 DB IO Service 与 Controller 这部分做成多实例部署，也就是说弄成集群，如果 DB IO Service 这部分有不同的实例，那就成了一个分布式系统
淘宝、新浪都是这么做的，当并发需求很大时，先是多实例部署，然后加一个负载均衡来分发请求到不同的实例，这就属于集群的范畴
当集群的性能还满足不了需求时，再将大项目拆分成小项目，这就属于分布式的范畴，然后分布式中的热点小项目再多实例部署，这就属于 分布式 + 集群 混合的范畴
2016-11-12 22:17
对于关联表，用得最多的就是关联查询，而关联查询都是以主表为核心，关联表只起一个桥梁的作用，所以不需要对关联表创建 model
对于关联表的维工作，主要是创建与删除，用一下 Db + Record 模式是极度方便的
2016-11-12 10:03
@lele111 仔细参照 jfinal demo 中的说明文件结合一下 jfinal 手册第一章中的快速上手去运行就一定可以
2016-11-11 21:26
@zempty handler 放行两次的属于我未听说过的第三种原因了，感谢分享
2016-11-11 17:34
@charlox arp.addMapping(...) 这些不要自己手写，用生成器会生成一个 "_MappingKit.java" 文件，是全自动搞定的
2016-11-11 16:45
所有 jar 可以在jfinal 社区首页下载，下载那个 jfinal all zip 文件，里面还有一个说明文件，详细说明了每一个 jar 包的作用
2016-11-11 16:42
@charlox jfinal 手册上专门讲了 oracle 自动生成主键的方法，配有源代码，可直接使用， oracle 事务级别确实需要显式设置，这是因为 jfinal 2.2 将默认级别提升了，而 oracle 又正好不支持这个级别， jfinal 2.3 会改进这里
