JFianl源码走读_6_框架总览

官方文档的JFinal的顶层架构图如下

浅谈web开发本质

    http web开发其实只是做了三件事，接收客户端的request、响应response、解析request填充response,为了降低低层开发者的难度，javaweb开发中，引入了webapp和容器，遵循servlet规范的webapp和容器便可以解耦，互相独立的被开发出来，容器是个可以通用的构件，可复用程度极高，而webapp则是根据具体需求来决定的，所以容器有tomcat，jetty,jboss等，而webapp的数量几乎是无法被统计出来的。既然容器有成熟的经过考验的产品，那么如何更有效率的开发webapp便是众多开发者考虑的问题了。    javaweb http请求-响应的大致流程如下    客户端request->http服务器获取请求流并解析、生成response响应流->递交给web容器处理->根据请求信息调用相应的webapp->填充response->返回客户端    上流程中的各个流程都是互相独立的，整个流程相当于一个流水线，而每个流程则相当于一个处理器，根据上游传递过来的半成品加工就好。实际上整个流程就是一个Handle链，只是这个handle比较大，仅此而已。

####webapp的代码重用

    软件开发是无限制追求重用的,比如web容器，而作为一个低级开发者，我们关注webapp这一层次的代码重用    既然使用基础的servlet，filter，listener也可以开发webapp，那么为何还有那么多的web开发框架推成出新，百花争妍呢？框架的存在意义是什么？    最终目的就是提高生产力，那么在软件开发中如何去提高生产力呢，让开发者实现同样的功能少写些代码，如此，一些企业或个人在开发的过程中，提高开发效率的一些辅助工具，逐渐的就形成了框架。如如日中天的struts2,springmvc,以及国人开发利器JFinal。这些框架就是webapp中的代码重用。

JFinal是如何提高生产力的

遵循COC原则，约定优于配置

    这个体现的最彻底就是JFinal中的acionMapping的实现了，actionMapping的实现确实相当精巧，作者利用其对webapp开发的深刻理解，抽象出了action对象，具体的还看之前的jfinal初始化内容。    既然需要实现action，而url到action之间又必须有关系，那么为什么还要去配置url到action的映射呢，通过约定，就无需想struts2那样，用单独的struts.xml来协助配置action了，也无需像springmvc那般必须使用注解来配置url-action映射了。

配置项少，且易于理解

    虽然Jfinal宣称零配置，实际上在具体webapp的配置中，还是有些必要的配置的，只是比较少，且可用代码注解配置。比如constants,routes,handlers,intercepters,plugins,相较于使用配置文件配置，优劣暂不评论，不过建议添加辅助的配置文件配置。当然jfinal是主打极速开发的，去除配置文件的干扰是可以理解的。对于routes配置，建议添加注解支持，或者利用某些手段自动配置。对于aciverecord的model到table的orm映射，也是建议添加注解配置，虽然在主配置代码中配置可以，但并不见得比xml配置本质上有什么提高。这些只是个人的一些理解。    尽管如此，jfinal的配置项确实相当少，且易于理解。

Jfinal架构容易理解，容易被扩展，源码清晰。

    jfinal的handle可自定义，intercepter可自定义。    plugin贯穿整个jfinal处理流程，便于于其他工具进行链接，同时享用第三方的功能和jfinal的极速开发。

activerecord支持，精巧的orm实现

    同actionMapping设计思路类似，既然实体类的属性需要与table中的列属性一一对应，那么遵循约定吧，不需要实体类的属性了，以key-value的形式来维护model，不但简化了持久层的建设，还可以在链接M-V中，动态的往model中添加属性。