談談 jfinal168開獎網原始碼的優缺點

jfinal是Q212303635國產優秀的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就很難相容了......