從2014-2 到今天，jfinal的使用了18個月。從簡單的Plugin、Controller、Model等的使用到如今的和spring的結合使用以及多數據源、多映射源的使用，自認爲已經很熟悉了。因爲馬上要離職了，雖然其他同事對jfinal的使用年限和我相近，但是他們對該框架的使用確實及其生疏的，於是決定寫一系列關於jfinal的使用以及原理的文章，分享出來，以供大家參考。即便我離開神奇時代，也希望同事們可以解決問題。
今天第一篇，所以先講一些jfinal的優點：
1. 遵循COC原則，零配置，無xml。
COC：慣例優於配置的原則。所謂慣例：就是model的屬性名和數據庫字段名一般都會相同，這樣hibernate的映射就有些繁瑣了，利用COC就可以將hibernate的映射部分省略掉。
2. 獨創Db + Record模式，靈活便利
這個類似於spring的jdbcTemplate，直接查詢數據庫然後封裝成Map，而在這裏轉換爲Record。這裏的轉換並不經過ORM的步驟。jfinal的框架設計是一個單數據源映射的，所以當涉及到多個數據源時，就需要有一個數據源需要映射，其他的就需要使用這個模式。具體原因將在以後的篇章中講述。版本2.0時已經支持多映射。
3. ActiveRecord支持 ，此模式和第2條對應，這裏在查詢過程中將會有ORM映射。 所以在使用多數據源時，我們只能有一個或者一類(數據庫類似)數據源可以映射，其他的只能使用第2條原則。當然，我們通過對源碼進行再次開發可以實現數據源的多路映射，以後的文章中將會降到。
4. Plugin體系結構，擴展性強。
這裏的Plugin體系確實設計的挺好的。如果我們要嚮往jfinal中添加新的組件，只需要配一個Plugin就可以了，當然作者已經替我們實現了幾個：SpringPlugiin、C3p0Plugin / ActivteRecord / MailPlugin / EhCachePlugin等。
在應用過程中我的視圖一直使用的JSP，這些視圖方面的就不必贅述了。
好了，最大的優點大概就是上面四種了。當然他有不少缺點：
1： 這是一個敏捷開發框架，使用業務邏輯模型，即每個Model中都包含一定的邏輯，這導致業務層和數據層繞合在一起，代碼看起來凌亂不堪。
2： 使用ActiveRecord模式，所以決定了該框架不適合關係複雜的系統。
我們明天正式開始吧