開源中國上的一篇帖子火了，我們一起吃個瓜吧哈哈，
先說jfinal是個啥：咱們先看看官網介紹
JFinal 是基於 Java 語言的極速 WEB + ORM 框架，其核心設計目標是開發迅速、代碼量少、學習簡單、功能強大、輕量級、易擴展、Restful。在擁有Java語言所有優勢的同時再擁有ruby、python、php等動態語言的開發效率！為您節約更多時間，去陪戀人、家人和朋友 :)
JFinal有如下主要特點：
MVC架構，設計精巧，使用簡單
遵循COC原則，零配置，無xml
獨創Db + Record模式，靈活便利
ActiveRecord支持，使數據庫開發極致快速
自動加載修改後的java文件，開發過程中無需重啟web server
AOP支持，攔截器配置靈活，功能強大
Plugin體系結構，擴展性強
多視圖支持，支持FreeMarker、JSP、Velocity
強大的Validator後端校驗功能
功能齊全，擁有struts2的絕大部分功能
體積小僅632K，且無第三方依賴
再看看jfinal的戰績：
2017
2016
看看官網就知道有多火了
然餓這麼火的項目也被人拿出來攻擊一波，當然我不建議直接評對錯，就看合不合適自己啦，下面我們看一下這位哥的“熱評”，其實這是一篇2013年的文章，打開後發現大家依然在懟發表以上言論的作者，我想從2013年被追到2019年該篇文章的作者應該也很奔潰，
原文如下：
標題：談談 jfinal 的優缺點 熱
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就很難兼容了......
看看網友回覆：
長達幾十頁的評論，看完以後後背有點發涼啊，這個作者會是神馬心情，不過針對jfinal還是有很多的爭論的，但是我認為關鍵是要看適不適合自己的項目，任何項目都會有有點優缺點，而且很多框架再不瞭解全部機構思路的時候評論他是不是有些班門弄斧啊
分享到:
閱讀更多 在我的瞳孔裡照見你 的文章
