谈谈 jfinal 的优缺点

光石头 发布于 2013/09/05 12:09
阅读 145K+
收藏 24

jfinal是国产优秀的web框架.jfinal短小精悍强大,易于使用.不过万事有度,省的太狠也不太好.

1.框架应该尽量兼容各种场景,因为你不知道以后的场景.框架是一个持续集成和更新的过程,对公司来说这是非常重要的技术积累.(ps:多个数据库总算基本场景吧......)

2.不应该整体使用map代替普通的javabean.基本是需要记忆数据库字段了,map也不方便IDE重构和手写错误的风险,也不适合对特殊字段进行注解,因为已经没有get set 方法了.

3.应该拥有IOC容器.每次都是自己手动new对象,如果真想追求极致的性能,ioc容器也应该提供吧.

4.需要更加完善的数据库事务,隔离级别,传播特性,支持多数据库,批量操作等,事务是非常严谨的!!!

5.第三方组件兼容.框架再强,也不能完成所有的任务,需要和第三方兼容,最好是官方已经做好,spring做的比较牛啊,几乎所有的主流第三方都能和它直接兼容,就连一直嫌弃spring的jfinal也提供了一个插件......

6.持续的兼容更新和维护.在天朝生存压力还是比较大的,老外则不同.例如:spring已经持续更新10年,而且版本兼容,文档等做的都比较好.我对fireworkflow很无语了.......

7.商业原因.大部分屌丝程序员都是打工的,需要掌握主流的东西,例如spring,这样即使跳巢,也不会掉价.

最后补充一句,我在jfinal的群里说过一个问题是sql group by 分页,jfinal的处理方式有问题,作者尽快修复下吧.


我澄清几点误区:

1.spring和Guice.说Guice比spring快多少,只是在启动阶段,启动完成后,bean被load到内存,运行速度是一样的

2.spring的开发速度也是很快的,通过好的封装开发方法,和代码生成辅助,开发效率会比jfinal更好些.

3.spring mvc 虽然使用了反射,但是是单例的,性能也不会太低.

4.spring的模块化较好,我使用了11个spring的jar,5M大小.这个也不算什么重量级的东西吧.....

5.如果前期没有设计好,想着以后扩展,你的下次升级API就很难兼容了......


是骡子是马拉出来溜溜:springrain vs jfianl的开发对比





加载中
6
JFinal
JFinal

    首先感谢楼主对JFinal的支持,提出了一些值得讨论的问题。JFinal之所以是这个样子有其自身的定位与权衡,很多功能不是不能做,而是能不能抵挡住诱惑而不去做。例如为Model做个跨库的支持也不是什么难事,但代码量会增大,复杂度提升,并且代码也会变得比较丑陋。

   其次JFinal 是基于一系列设计思维来打造的,其中一项指导思想源于爱因斯坦的:A clever person solves a problem. A wise person avoids it. 我再加上一句 A stupid person makes it. JFinal 不是要去解决所有问题,相反是去尽可能避免问题。就好比JFinal 不去解决各库之间的兼容性问题,从而可以避免类似于hibernate HQL这类设计带来的复杂性,也同时避免了 HQL 所引发的一系列其它问题。

    时间不多,我简单回答一下有关问题:

1:JFinal从来不打算尽量兼容各种场景,也不知道开发者未来的场景是怎样的,而是提供一个微内核 + 全方位扩展架构,让开发者可以充分发挥自己的想象空间。无招胜有招。

2:首先JFinal Model并不是一个map,仅仅是用map存放了数据而已。其次数据库字段有很多办法不需要记忆,例如可以在YourModel中定义字段名常量,还可以自己创建 getter、setter方法,然后就与普通javabean 没什么区别了。JFinal从来不阻止你将Model改造成传统javabean,只要你愿意写这些无聊的setter、getter就可以。至于什么重构和手写错误的风险,建议楼主学习一两门动态语言再来评论。

3:IOC容器通常用来实现AOP,JFinal天然有更简洁的支持,无需再用IOC。有了IOC就必定会有一些无聊的配置。

4:JFinal 贴近JDBC,利用它来做事务,JDBC所能发挥的威力,JFinal让其全部展现出来,不需要再添加新的概念。

5:JFinal 的 Handler、Interceptor、Controller、Model、Render、Plugin都可以在不同的情况下兼容或者扩展第三方组件。Spring就是这么支持的,支持Spring是因为照顾一下少数习惯于Spring的开发者,将来会考虑去掉spring的支持。

6:JFinal 一直在更新和维护,昨天还弄了maven支持。

7:主流的东西迟早也会变得不主流,不愿接受新东西才是更大被淘汰的风险。

8:sql group by 没发现有错误

哈库纳
哈库纳
回复 @名城 : 这种人一般公司是不太会想要的,首先啥都不懂遇到一点难题百度不到了就做不下去了。 只会坏了公司项目,so你懂的,只要公司负责招人的不是很烂这种人通常情况下是找不到工作的。
名城
名城
学jfinal来跟波总借个光,现在培训学校出来的IT人员也比较多,他们单纯就是为了做项目,而里面封装的那些东西他们不需要去理解,只要能项目做出来就可以了。
紫电清霜
紫电清霜
回复 @JFinal : 是啊,关于这些争论,我也是一直很关注,所以时隔几年后再来看看,波总后续对jfinal的改进简直帅的无话可说!!!
悟空o邓林森
悟空o邓林森
回复 @JFinal : 6
Krash
Krash
回复 @JFinal : 支持!!!
下一页
5
缪斯的情人
缪斯的情人

jfinal欢迎任何观点和意见。

1.框架的适用场景。这个问题真的没法一言蔽之,任何一个框架不可能全部覆盖千万用户的适用场景,一千个用户有一千个哈姆雷特。所以只能说覆盖常用场景,对特殊场景提供可扩展性。

2.至于map替代bean的方式,我不敢妄加多言,只是揣测作者用意,在于借鉴动态语言像ROR,django的一些特性,奈何java语言本身限制,无法做到动态语言那般优雅。至于你说的IDE检查错误,这个是你过分依赖IDE的结果,假如你换门ruby,python试试,谁给你检查错误?

3.IOC容器,其实jfinal也有。本质上来说IOC这玩意,有人觉得是个噱头而已,有人就非常喜欢。有些时候简单的问题容易想复杂,往往很多人就忘记了还能new一下。

4.事务这一块,最初jfinal是比较弱,近期也在改进,加入了嵌套事务。隔离级别和事务传播这些都是jdbc自有的,jfinal基于jdbc,自然具备。

5.第三方组件兼容。呵呵,这个不知道网友们扩展出多少第三封组件库了,redis,shiro,cron···。官方不会提供这么多组件的,所谓micro core和muti plugins,这和spring是不一样的。

6.持续版本更新和兼容。这个不必担心,只要作者健在(原谅我波波)。况且社区还在,未来会有新动作(期待吧)。

7.商业原因。这个····太汗了。一个只会用框架的程序员,你觉得跳几次槽会掉多少身价。况且jfinal也没说不让你学其他的了,这···无力吐槽了。

最后还是代表jfinal社区(其实我也是个jfinal屌丝,坐等波波大婶吧)说一句jfinal欢迎各种声音,也会积极吸取大家优秀的意见。

胖猿
胖猿
回复 @Kinghui : 底层其实还是map
柯南君Arron
中小型项目的要求就是快速开发,这是jfinal的最大的优势之一回复 @消枫 :
Z
Zempty
回复 @消枫 : java也不是彻彻底底地面向对象啊
Kinghui
Kinghui
回复 @消枫 : 你估计是没有用过jfinal,jfinal支持javabean,只是一般人偷懒没直接model映射了,然后就是用get set来搞。不是不支持懂吗?
消枫
消枫
jfinal这玩意 也就只能用来做简单的增删改查项目,大型项目如sap,erp之类,更在于业务对象的封装与架构。javabean的存在不只是承载数据,对象的封装是map无法做到的。javabean的真正意义在于业务对象的封装与架构。如果用map来做,那就不要使用java语言。 记住, java之所以牛逼,就在于彻彻底底的面向对象.
下一页
2
绝望的八皮
绝望的八皮

看了评论不得不吐槽一下又。java语言罗嗦,java 的框架罗嗦,整个java社区就是各种设计过度,自从了解了其他语言之后,再回过头看java的各种,真不知道怎么想的是。。其实jfinal思想不像是java 的框架了。所以很多让人不好接受的,如果理解到这个才算是理解到jfinal的到底要表达什么。再进一步,其实还是换个语言吧哈哈。

2
等烟雨
这世界 本就没有最好,都是工具 对于用的人来说 那个适合自己那个好。jfinal就是一把小匕首,他便携,身手敏捷的人可以轻松挥洒随意扩展。spring类框架稍微大一点,但是好比一把狙击枪,携带和保养不易,但是它有一堆的扩展,消声器,瞄准目镜,指哪儿打哪儿。正所谓 大部分人纠结的问题,我也都纠结过,前段时间 我也想用jfianl,但各种支持,需要各种自己动手扩展,需要各种写插件,各种自己兼容,相比之下你不需要性能,你就可以适当选择更适合你的兵器,小个子就拿小兵器,大胖子就拿大兵器,敏捷英雄不要抢法师装备。谢谢!!
2
湖水没了
湖水没了
用jfinal还不如用php
1
紫电清霜
紫电清霜
还是喜欢map更多,觉得javabean的一堆getter和setter很繁琐,可能是有些代码洁癖,如果java这门语言可以像Python3.X那样,有个革命性的从语法本身的改变那就好了。
土豆去哪里
土豆去哪里
map不怕写错的话
张旭龙
回复 @光石头 : 主要是限制, seter和geter 是限制到类里的不能随意的增加改变字段, 而map就很容易, jfinal里你查出来 blog 可以很灵活的在需要的地方 blog.put('comments',comments) 而且这样和json无缝衔接
MayMatrix
MayMatrix
map或JSON都比get set对好用简洁,最近用的是数组,定义好模版后面直接用数字,简洁到家了
路小磊
路小磊
回复 @屁屁果 : 代码里看着一堆setget方法不难受么……
光石头
光石头
get set 也不需要手写,都是自动生成的,这样使用起来应该和map没有任何区别啊
1
lwei
lwei

从两位作者的讨论中学到了东西,真心感谢两位。

没有用过springrain也没有用过jfinal,所以技术细节上没有发言权。只想说每个框架都有其设计理念,一个理念之所以能够区别于其它理念而独存于世,就是因为它接受了一些东西而反对了另外一些东西。再考虑到历史局限性,一个框架必然只适用于某方面的场景。若要说玩象棋的没有玩围棋的高明,你会同意吗。只要一个框架盯准目标,努力做到极致,用户会做出选择,其它都是浮云吧。

花开两朵,各表一枝。客观上说,摘掉有色眼镜来看,楼主喷的算是很文明了。倒是个别选边站的看客不淡定。做框架的人磨磨嘴皮子,叫护犊,那是人之常情。用框架的人,还是应该保持开放性心态吧。如果在一个人眼中,只有锤子能当工具,他是会用锤子去锯木头的。

追梦的南瓜
追梦的南瓜
看了这么多评论,我觉得你说的很有道理。前面的都是在试图改变对方的思路!但是每个项目的应用场景不同!所以使用者各取所需就好了!但是谢谢两位的开源让大家学到东西!
光石头
光石头
嗯,你的评论很中肯也很理性.框架甚至技术都有自己的使用场景,这一点我也是深有感触......
1
宏哥
宏哥

引用来自“JFinal”的答案

    首先感谢楼主对JFinal的支持,提出了一些值得讨论的问题。JFinal之所以是这个样子有其自身的定位与权衡,很多功能不是不能做,而是能不能抵挡住诱惑而不去做。例如为Model做个跨库的支持也不是什么难事,但代码量会增大,复杂度提升,并且代码也会变得比较丑陋。

   其次JFinal 是基于一系列设计思维来打造的,其中一项指导思想源于爱因斯坦的:A clever person solves a problem. A wise person avoids it. 我再加上一句 A stupid person makes it. JFinal 不是要去解决所有问题,相反是去尽可能避免问题。就好比JFinal 不去解决各库之间的兼容性问题,从而可以避免类似于hibernate HQL这类设计带来的复杂性,也同时避免了 HQL 所引发的一系列其它问题。

    时间不多,我简单回答一下有关问题:

1:JFinal从来不打算尽量兼容各种场景,也不知道开发者未来的场景是怎样的,而是提供一个微内核 + 全方位扩展架构,让开发者可以充分发挥自己的想象空间。无招胜有招。

2:首先JFinal Model并不是一个map,仅仅是用map存放了数据而已。其次数据库字段有很多办法不需要记忆,例如可以在YourModel中定义字段名常量,还可以自己创建 getter、setter方法,然后就与普通javabean 没什么区别了。JFinal从来不阻止你将Model改造成传统javabean,只要你愿意写这些无聊的setter、getter就可以。至于什么重构和手写错误的风险,建议楼主学习一两门动态语言再来评论。

3:IOC容器通常用来实现AOP,JFinal天然有更简洁的支持,无需再用IOC。有了IOC就必定会有一些无聊的配置。

4:JFinal 贴近JDBC,利用它来做事务,JDBC所能发挥的威力,JFinal让其全部展现出来,不需要再添加新的概念。

5:JFinal 的 Handler、Interceptor、Controller、Model、Render、Plugin都可以在不同的情况下兼容或者扩展第三方组件。Spring就是这么支持的,支持Spring是因为照顾一下少数习惯于Spring的开发者,将来会考虑去掉spring的支持。

6:JFinal 一直在更新和维护,昨天还弄了maven支持。

7:主流的东西迟早也会变得不主流,不愿接受新东西才是更大被淘汰的风险。

8:sql group by 没发现有错误

决定不做什么

比决定做什么更难

楼主还远远没有达到这个层次

一个ORM就足够说明问题了。 

光石头
光石头
呵呵
1
宏哥
宏哥

最重要的是

jFinal是极少数宏哥能给出正面评价的开源东西

注定了楼主的失败

楼主要挑战的是两个凡是

犹如拿菜刀挑战虎式坦克

虎式坦克唯一能做的, 就是让你死的快一点, 这样痛苦比较少,据说这个叫做

人道

洗洗睡吧

金贞花
金贞花
O(∩_∩)O哈哈哈~
光石头
光石头
呵呵
1
opal
opal
不能快速响应用户需求/变更的东西,都不是好东西。
光石头
光石头
http://my.oschina.net/baobao/blog/159768
光石头
光石头
真理!我最迟明天,会写一个完整功能和jfinal对比,看看哪个响应更迅速……
返回顶部
顶部