也聊聊JFinal

技术小站： http://www.kiratechblog.com/ 

最近给项目选型的时候，选了JFinal这套框架，开始的时候有些小伙伴会不理解，在Java的世界里面那么多的MVC框架，那么多的持久化框架，怎么就选了JFinal这玩意。

吐槽一下

这就不得不从比较正派的J2EE框架说起了（好吧。。。我是个经常不按照常理出牌的工程师），一般企业应用开发，大家都会顺手拈来SSH。当然，估计现在还说SSH估计有点老了（Struts你还行么。。。），现在比较常用的做法是Spring MVC、Hibernate/IBatics这样的组合了。但是不知道大家发现了没有，很多的时候，其实我就只是需要有个简单的方式做个CRUD，我不想要那么多的实体类，看着都烦人。又或者我其实就只是想要一个MVC的框架，看看别人家PHP的MVC多简单啊，没有这配置那配置的。我不需要那么多的IOC，我不想新建一个控制器还得先建立一个什么接口，然后再在控制器里面实现它，我认为整个项目到处都是IOC的话简直就是对设计模式的滥用。。。我受不了Spring调试的时候启动那么慢，开发的时间很宝贵，热部署的过程能越快越好（还有一些槽点，不想吐了。。。用过的都懂的）

JFinal

由于种种的不满，于是我发现了JFinal这货。乍一看，国产框架！好吧，这年头国产的东西谁敢用啊，就好比买奶粉都买国外的，国内的都不敢买一样。

国内的奶粉敢不敢买我不好说，不过选框架这一点来说少年我还是很有把握的。JFinal这货的下面这几个特点一下子就吸引住了我：

1. 极少的配置，没有Spring那些这里配一下，那里配一下的烦恼

2. 对数据库的操作做了封装，不用我去考虑配置数据库连接池配置的问题，不用去搞一堆的DataModel，而且DataModel的功能比Hibernate的灵活多了，有那么一些Ibatics的影子在里面的说。好吧，简单粗暴的CRUD功能提供给我了

3. Restful。其实这会导致开发的时候有那么一些不习惯，没有Session可以弄了。。。但其实这样是好的，这样的话后端做负载均衡就简单很多啦。（企业应用这些玩意一般都不怎么需要搞的这么高端，和其他应用不大应用，一般性能最大的瓶颈是后端数据处理那里。记得甲方大爷要求一个高峰期几个人同时在线的应用要做Apache的负载均衡，劝也劝不了。。。T_T别这样啦。。）

4. 简单。这也是选用这套框架的一个很重要的原因。够简单，我把文档给我同事看了不到半天就玩的很熟了。大大的降低了培训成本。

5. 开源。好吧，我已经把JFinal的源码搞下了，稍稍改动过了，毕竟这货有那么几个数据库的方法居然没提供给我，搞的不得不亲自动手。当然为了统一校验和前端界面的写法，也把校验的位置稍稍做了些调整。JFinal的源码还是比较简单易懂的，调整起来也比较好调整

总结

总的来说，JFinal这框架还是挺好用的，简单小巧，但是该有的基本功能还是比较齐全的，好比一把小匕首，看到敌人后可以快速的给它来一下。但是对于很大型的项目合不合适就暂时没办法考究了（说不定那天碰到一个硬汉，匕首捅不动一点也不奇怪。。这人在江湖飘，各种技术都多了解下没坏的说～），不过少年我用到现在还没发现它有什么不好的，除了那么几个必备的API居然没提供之外。顺带一说，基于JFinal的这个项目进展的挺好的，由于培训成本特别的低，其他小伙伴一下子就上手了，省了不少时间