最近給項目選型的時候，選了JFinal這套框架，開始的時候有些小伙伴會不理解，在Java的世界里面那么多的MVC框架，那么多的持久化框架，怎么就選了JFinal這玩意。
吐槽一下
這就不得不從比較正派的J2EE框架說起了（好吧。。。我是個經(jīng)常不按照常理出牌的工程師），一般企業(yè)應(yīng)用開發(fā)，大家都會順手拈來SSH。當(dāng)然，估計現(xiàn)在還說SSH估計有點老了（Struts你還行么。。。），現(xiàn)在比較常用的做法是Spring MVC、Hibernate/IBatics這樣的組合了。但是不知道大家發(fā)現(xiàn)了沒有，很多的時候，其實我就只是需要有個簡單的方式做個CRUD，我不想要那么多的實體類，看著都煩人。又或者我其實就只是想要一個MVC的框架，看看別人家PHP的MVC多簡單啊，沒有這配置那配置的。我不需要那么多的IOC，我不想新建一個控制器還得先建立一個什么接口，然后再在控制器里面實現(xiàn)它，我認(rèn)為整個項目到處都是IOC的話簡直就是對設(shè)計模式的濫用。。。我受不了Spring調(diào)試的時候啟動那么慢，開發(fā)的時間很寶貴，熱部署的過程能越快越好（還有一些槽點，不想吐了。。。用過的都懂的）
JFinal
由于種種的不滿，于是我發(fā)現(xiàn)了JFinal這貨。乍一看，國產(chǎn)框架！好吧，這年頭國產(chǎn)的東西誰敢用啊，就好比買奶粉都買國外的，國內(nèi)的都不敢買一樣。
國內(nèi)的奶粉敢不敢買我不好說，不過選框架這一點來說少年我還是很有把握的。JFinal這貨的下面這幾個特點一下子就吸引住了我：
- 極少的配置，沒有Spring那些這里配一下，那里配一下的煩惱
- 對數(shù)據(jù)庫的操作做了封裝，不用我去考慮配置數(shù)據(jù)庫連接池配置的問題，不用去搞一堆的DataModel，而且DataModel的功能比Hibernate的靈活多了，有那么一些Ibatics的影子在里面的說。好吧，簡單粗暴的CRUD功能提供給我了
- Stateless。其實這會導(dǎo)致開發(fā)的時候有那么一些不習(xí)慣，沒有Session可以弄了。。。但其實這樣是好的，這樣的話后端做負(fù)載均衡就簡單很多啦。（企業(yè)應(yīng)用這些玩意一般都不怎么需要搞的這么高端，和其他應(yīng)用不大應(yīng)用，一般性能最大的瓶頸是后端數(shù)據(jù)處理那里。記得甲方大爺要求一個高峰期幾個人同時在線的應(yīng)用要做Apache的負(fù)載均衡，勸也勸不了。。。T_T別這樣啦。。）
- 簡單。這也是選用這套框架的一個很重要的原因。夠簡單，我把文檔給我同事看了不到半天就玩的很熟了。大大的降低了培訓(xùn)成本。
- 開源。好吧，我已經(jīng)把JFinal的源碼搞下了，稍稍改動過了，畢竟這貨有那么幾個數(shù)據(jù)庫的方法居然沒提供給我，搞的不得不親自動手。當(dāng)然為了統(tǒng)一校驗和前端界面的寫法，也把校驗的位置稍稍做了些調(diào)整。JFinal的源碼還是比較簡單易懂的，調(diào)整起來也比較好調(diào)整
總結(jié)
總的來說，JFinal這框架還是挺好用的，簡單小巧，但是該有的基本功能還是比較齊全的，好比一把小匕首，看到敵人后可以快速的給它來一下。但是對于很大型的項目合不合適就暫時沒辦法考究了（說不定那天碰到一個硬漢，匕首捅不動一點也不奇怪。。這人在江湖飄，各種技術(shù)都多了解下沒壞的說～），不過少年我用到現(xiàn)在還沒發(fā)現(xiàn)它有什么不好的，除了那么幾個必備的API居然沒提供之外。順帶一說，基于JFinal的這個項目進(jìn)展的挺好的，由于培訓(xùn)成本特別的低，其他小伙伴一下子就上手了，省了不少時間
