JFinal 3.5 发布,将能上的菜先上了

JFinal
 JFinal
发布于 2018年10月08日
收藏 27

    jfinal 新功能经过 6 个月的酝酿、开发,在大幅度的创新来临之前,jfinal 3.5 这一版先稳一稳,趁着国庆长假,将能上的菜先上了。

    jfinal 3.5 这一版针对这 6 个月以来用户反馈最强烈、最频繁的需求进行了开发,同时对原有代码进行了极其精致的优化与打磨。

    jfinal 3.5 诸多内部优化值得升级使用,诸多基础性调整为下一步进化做好准备。

1、Controller 依赖注入

    jfinal 3.5 添加了 Controller 依赖注入功能,使用前需要配置启用该功能:

public void configConstant(Constants me) {
    me.setInjectDependency(true);
}

    然后在 Controller 中只需对属性使用 @Inject 注解即可:

public class MyController extends Controller {

    @Inject
    Service service;

    public void index() {
        service.justDoIt();
    }
}

    添加该功能主要目标是为了自动化触发业务层 AOP 与进一步减少代码量,如上代码中的 Service 中使用的 @Before 配置的拦截器会自动生效,而老版本需要手动 enhance 一次。

2、Interceptor 依赖注入

    @Inject 还可以向拦截器属性注入依赖对象,用法与 Controller 之中完全一样:

public class MyInterceptor implements Interceptor {

    @Inject
    Service service;

    public void intercept(Invocation inv) {
        service.justDoIt();
    }
}

    jfinal 依赖注入功能与 spring 有着本质的不同,jfinal 依赖注入的核心目标是为了实现 AOP 自动化与节省代码量,而且与 IOC 毫无关系,更不需要 IOC 容器。极简设计,实现该功能只用了 243 行代码。

3、Aop 任意时空支持 AOP 及 Inject

    jfinal 3.5 添加了 Aop 工具类用来全面取代老版本中的 Enhancer,可在任意地方通过 Aop.get(…) 方法创建 AOP 代理对象,实现 AOP 功能的同时进行依赖注入:

Service service = Aop.get(Service.class);

    以上代码会创建 Service 对象,如果 Service 中使用了 @Before 配置过拦截器将会自动生效,如果 Service 中的属性使用了 @Inject,则会被注入依赖对象。还可通过  Aop.inject(...) 方法来注入依赖对象:

Service service = new Service();
service = Aop.inject(service);

    以上代码会为 service 中的 @Inject 属性注入依赖对象 ,Aop.inject(...) 方法相对于 Aop.get(...) 少一个对象创建过程。Aop 可以在 Controller、Interceptor 之外快捷使用 AOP、Inject 功能。

4、主干版本加入 action 参数注入功能

    由于老版本照顾了 java 1.6、1.7 用户编译级别为 1.6,action 参数注入功能做到了 jfinal-java8 分支版本之中。 jfinal 3.5 最低要求 JDK 1.8,  action 参数注入功能自然也就做到了主干之中:

public class LoginController extends Controller {
    public void index(String userName, String password) {
        Ret ret = service.login(userName, password);
        renderJson(ret);
    }
}

    以上 index() 这个 action 被注入了 userName、password 形参,省去了对 getPara、getFile 系列方法的调用代码,将进一步提升开发效率。该功能还支持 File、Model、RawData、Date 等常用类型,还可以通过扩展 IParaGetter 接口实现注入任意类型的数据。本功能由 @玛雅牛 大神贡献,再次感谢 @玛雅牛。

5、jetty server 模块升级为 2018.11 版本

    jetty server 模块升级到 jetty 最新版 9.4.12.v20180830, 由于是 java 8 起步,用户可自由升级 jetty 到未来的更高版本。升级后的 jetty server 支持所有版本的 eclipse,支持 IDEA 热加载,并且统一 eclipse、IDEA 启动参数:

JFinal.start("src/main/webapp", 80, "/", 5);

    老版本 jetty server 无法在部分高版本 eclipse 中使用,无法在 IDEA 下支持热加载,jetty server 最新版 maven 坐标如下:

<dependency>
    <groupId>com.jfinal</groupId>
    <artifactId>jetty-server</artifactId>
    <version>2018.11</version>
</dependency>

6、NotAction 注解

    NotAction 注解用于 Controller 上原本为 action 的方法之上,可以强制该方法不成为 action:

public abstract class BaseController extends Controller
    
    @NotAction
    public void getLoginUser() {
        ......
    }
}

    以上代码中的 getLoginUser() 将不会成为 action,不会生成访问路由,老版本中的 @Before(NotAction.class) 可改用 @NotAction 注解实现。

7、Controller 添加 getRawData()

    getRawData() 便于接收客户端发送过来的 json 或者 xml 数据:

public void index() {
    String jsonStr = getRawData();
    User user = FastJson.getJson().parse(jsonStr, User.class);
}

    getRawData() 有助于提升 API 型项目的开发体验,在减少代码的同时进一步提升开发效率。

8、Controller 添加 getKv()

    getKv() 将表单参数封装成 Kv/HashMap 对象,方便使用其中的一些工具方法:

public void index() {
    renderJson(getKv());
}

9、enjoy 模板支持自定义 Field表达式

    如下代码将支持 object.field 表达式访问  isField() 方法:

Engine.addFieldGetterToLast(new FieldGetters.IsMethodFieldGetter());

    通过扩展 IFieldGetter 接口,可以自由定制 object.field 表达式的获取方式。

10、改进 ClassPathSource

     解决 URL.openConnection() 在 linux 下打开文件句柄不能及时关闭的问题。

    上述是一些看得到、感知得到的增强与改进,此外还有超过 50 项的内部优化、打磨是看不到的,后续会在 changelog 中整理出来。精益求精的 jfinal 3.5 版本,值得你升级。

     One More Thing:
     近几天俱乐部将会在线直播讲解 jfinal 3.5 与 club 1.6 的新功能与新用法。与 jfinal 3.5 一同发布的还有俱乐部专享项目 jfinal club 1.6,该项目提供一套极简的权限管理以及内容管理后台,截图与功能介绍猛击 传送门,现在就加入俱乐部获取专享福利:http://www.jfinal.com/club 

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:JFinal 3.5 发布,将能上的菜先上了
加载中

精彩评论

理工男海哥
理工男海哥
国内还有很多开源的作者,但是真正像波总这样沉淀下来,通过元思维的方式去思考开发者的需求的太少太少了,使用JFinal的这几年里,从来没有因为JFinal的设计问题影响到产品。因为JFinal灵活的设计和国内强大的口碑,使我的个人作品 #Jboot# 也因此收获了不少的用户,使我个人也得到了认可。在此呼吁大家也参与到JFinal的生态贡献中来。
JFinal
JFinal

引用来自“陳建勳”的评论

請問,這個是不是已經默默超越spring了呀?
在学习成本、开发效率、代码量这三个 jfinal 的核心目标上远远胜于 spring
TerryZ
TerryZ
前排支持波总,idea 和 eclipse 都支持热加载太棒了
小强哥unas
小强哥unas
大话不多说了,之前创业用jfinal的简单快速的特点的确解决了中小团队面临的技术太多太复杂的情况,现在也在小项目上一直在使用jfinal。波总给代码开发回归简洁树立了典型,也希望支持更多三方扩展,毕竟很多人还是希望少操心,当然jboot也做得不错,相辅相成。
长篇小说
感谢波总推出新产品!我是jfinal使用者,大约使用有3年时间了,原来接触过各式各样框架,都没有顺利落地项目,接触jfinal之后,开始逐步提升,并且得到了波总的耐心指点,赚多少钱不敢自夸,但肯定比上班族多多了。所以我认为,评判一个项目,主要在于他产生的实际价值,在于肯定创造人的无私奉献精神!

最新评论(116

阿黑呀
阿黑呀
jfinal真的很方便,个人开发必备
badouyuren
badouyuren
憨憨电影已升级
小强哥unas
小强哥unas
大话不多说了,之前创业用jfinal的简单快速的特点的确解决了中小团队面临的技术太多太复杂的情况,现在也在小项目上一直在使用jfinal。波总给代码开发回归简洁树立了典型,也希望支持更多三方扩展,毕竟很多人还是希望少操心,当然jboot也做得不错,相辅相成。
长篇小说
感谢波总推出新产品!我是jfinal使用者,大约使用有3年时间了,原来接触过各式各样框架,都没有顺利落地项目,接触jfinal之后,开始逐步提升,并且得到了波总的耐心指点,赚多少钱不敢自夸,但肯定比上班族多多了。所以我认为,评判一个项目,主要在于他产生的实际价值,在于肯定创造人的无私奉献精神!
JFinal
JFinal

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“JFinal”的评论

jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码

引用来自“哈库纳”的评论

添加多少行代码不重要,从功能上来讲已经和 spring-mvc 趋同了。 我想这就是 山哥 的意思。

波总说的臃肿应该是代码上的臃肿,对于 1周功能就要上线,下一周就要完成一个版本的迭代的实际情况没人会关注是用 143 行还是 50万行实现 AOP。 而是是否可以用 143 行完成业务开发,并且稳定运行在线上。
jfinal 是 MVC + ORM,spring 也有这些功能,在功能上有相同的地方这个在所难免

关于代码量的问题,不管别人关不关心,jfinal 必须是要极度关心的。每一行代码对于 jfinal 来说都是要维护的,多一行代码就多一点维护成本

多一行代码就增加一点 bug 的概率,这点就跟说话一样,所谓言多必失,同样一个功能,同样水平的人写的代码,代码量多的那个在概率上来说 bug 概率会高。 bug 概率关系到系统稳定性
哈库纳
哈库纳

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“JFinal”的评论

jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码
添加多少行代码不重要,从功能上来讲已经和 spring-mvc 趋同了。 我想这就是 山哥 的意思。

波总说的臃肿应该是代码上的臃肿,对于 1周功能就要上线,下一周就要完成一个版本的迭代的实际情况没人会关注是用 143 行还是 50万行实现 AOP。 而是是否可以用 143 行完成业务开发,并且稳定运行在线上。
JFinal
JFinal

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~
jfinal 3.5 的重要功能 aop 仅添加 143 行代码,怎么可能变成臃肿无比的 spring,想变成 spring 那样臃肿起码得再加 50 万行代码
JFinal
JFinal

引用来自“陳建勳”的评论

請問,這個是不是已經默默超越spring了呀?

引用来自“JFinal”的评论

在学习成本、开发效率、代码量这三个 jfinal 的核心目标上远远胜于 spring

引用来自“kut”的评论

哈哈哈……笑话。

引用来自“JFinal”的评论

我前面说的是在学习成本、开发效率、代码量三个维度 jfinal 远胜 spring。spring 胜在用户基数以及生态。

用过 5 年的 Spring,6 年的 jfinal,在大概率上我的判断比你要准确。几乎可以肯定的说你没用过 jfinal 超过三天。

做 IT 这一行的,理性判断是基本要求。大脑多运行在理性通道,感性通道很不可靠,尤其是现代社会感性通道已成为人类做出正确判断的重大障碍

引用来自“kut”的评论

见你的回答挺有趣的,也不知道多少无知程序员中了你的毒。知道的人笑笑就好,不知道的能远离的就远离吧。

引用来自“青苗”的评论

Jf 为数不多坚持下来并活的还可以的框架,不用的同学也不要冷眼嘲讽,你不用就可以没必要这样子。
还是同为开源人更能理解开源人啊👍

做个东西不容易,做个好东西更不容易,做个好东西坚持七年极不容易,做出来好东西不被看客胡乱臆测更是不可能

这类看客也只有通过贬损强者来证明自己的弱小了

真正有本事的开源人用代码说话,而只会臆测的看客只用屁股说话
JFinal
JFinal

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。
用 Interceptor 、Enhancer 实现 Aop 是 jfinal 七年前第一个版本就有的东西,jfinal 3.5 添加的这个 Aop.java、AopFactory 与 IOC 完全无关,更不需要 IOC 容器,根本谈不上是回到 Ioc & aop 这条路上来,更谈不上饶了好大一圈,143 行代码而已


其一,jfinal 的 Aop 七年前就有了,其二 Ioc 根本不需要,所以你说的 “终于回归到 ioc & aop” 这个是纯属不粘边

jfinal 3.5 对 aop 仅增加了 143 行代码,只是为了省代码引入依赖注入,而且设计目标与设计方式与 spring 截然不同

jfinal 最擅长的事情是消解、消灭一些不必要的概念,让事情变得简单舒适。这个从 jfinal 3.0 发布的模板引擎会有更切实的体会:https://www.oschina.net/news/81225/jfinal-3-0-released
Role
Role

引用来自“哈库纳”的评论

终于回归到 ioc & aop 这条路上来了, 感觉 jFinal 饶了好大一个圈子才回来。

引用来自“山哥”的评论

哈哈,当初的初心是好的,但是维护着维护着就变成了另外一个 Spring,唉~~~

引用来自“Role”的评论

实现的底子不同。

引用来自“山哥”的评论

重复造轮子了

引用来自“Role”的评论

那也要看随家卖的轮胎耐用跑得快的呢。😃

引用来自“山哥”的评论

哈哈
👌
返回顶部
顶部