2016-09-08 18:30
jfinal 社区是对于点赞按钮摆放的逻辑是这样的：社区希望用户在看完内容才去点赞，而用户看完内容自然目光就到了底部。如果放在上面，用户可能还要往上滚动屏幕再去点赞，就不太方便了，当然，这个后续还要多多听取用户反馈，可以随时调整的。感谢反馈，赞一个 ^_^
2016-09-08 13:58
ActiveRecordPlugin 有很多重载的构造方法，支持直接传入最朴素的 DataSource 对象来构建，感谢分享，赞一个 ^_^
2016-09-08 13:41
我习惯于这样做业务层：
public class XxxService {
public static final XxxService me = new XxxService();
final Xxx dao = new Xxx();
public Ret justDoIt(...) {
if (...)
return Ret.error("msg", "xxxx");
....
return Ret.ok(key, value);
}
}
这样做以后，外界可以这样调用：XxxService.me.justDoIt(...); dao 对象仅供 XxxService 内部使用，而且由于 me 对象是 static 的，所以内部所有其它的属性和方法都不要弄成 static 的
此外，如果用到业务层 AOP，将 new XxxService() 改成 Duang.duang(XxxService.class) 即可
2016-09-08 13:37
@冰雨 补充一下前面的回复：model 中不要创建 dao 对象以后，将 dao 对象创建在 service 层中这样来：private static Xxx dao = new Xxx(); 记得是 private，这样就防止其它业务插手本业务的事情
收到了你的捐助，非常感谢你的支持
2016-09-08 12:40
jfinal 项目建议分为 MVCS 四层结构：
1：M 层用 jfinal 2.2 生成，model 中不要使用 static Xxx dao 这样的对象，避免新手误用，model 中只放一些与字段状态相关的方法，例如 User 这个 model 你可以针对 status 字段，放一个 public boolean isStatusOk() 这样的方法
2：V 层就是展现层，尽可能只去展现数据，避免复杂逻辑
3：C 是控制层，只负责得到前端参数，转调业务层，render。避免写业务逻辑，绝不可写数据库查询之类的代码
4：最最核心是 S 业务层，基本上来说， 95% 以上的代码要写在这里，只要是对数据库的操作代码也全部写在这里。如果业务层以外需要操作数据库，那么也要先在业务层去创建方法，然后再让业务层以外去转调这个业务层代码，这样可实现尽可能大的代码重用
5：事务控制，我个人习惯于使用 Db.tx(...) 来做，如果要用拦截器，建议使用业务层拦截器，控制层坚持只做我前面 3 中所说的事情
6：只在需要的时候使用接口、抽象类，业务层在绝大部分情况下不需要使用接口，直接是 XxxService.java 就可以了
jfinal 社区官网再完善一段时间会抽取出里面比较通用的功能开放出来，多多关注社区动态
2016-09-08 11:35
getBoolean("devMode",false); 后面的 false 是指，当配置文件中没有 devMode 这个配置的时候，就使用后面这个默认值： false。 理解成：当配置不存在时，给指定一个值
2016-09-08 10:10
用 maven 的话，需要在 pom.xml 中添加相应的 dependency，不能采用添加 jar 包的方式，建议先学一学 maven 的基本使用
2016-09-08 10:05
所以说，jfinal 建议 json 的 keyName 也使用驼峰方式命名，就可以直接让jfinal 2.2 生成的 Model 直接被 fastjson 与 jackson 反序列化了。上次我发给你的那个 JFinalJson 与 FastJson 结合起来的例子还在不？ 感谢分享，先赞一个 ^_^
