jfinal 使用以及源码分析--序言

     从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模式，所以决定了该框架不适合关系复杂的系统。

   我们明天正式开始吧