诚如标题，这次我们就来探讨下jfinal中的核心组件
Controller。
1. 概述
作为标准MVC三层架构里的 C 层，在jfinal中拥有共同的基类，就是这个Controller了，这也是jfinal强制约束的。
正如“选择太多等于没有选择”， 在恰当的时候进行强制的约束，不给使用者以过多的抉择，反而不失为一种好的框架设计准则。
2. 定义
jfinal在大量参考了工程经验之后，所构建的Controller类中被填入多达上百个public方法，抽取了大量的重复性代码。作为子类的自定义Controller在无特殊的业务需求的情况下只需要简单的调用即可，这也符合jfinal一贯宣称的“开发迅速、代码量少、学习简单”等特点。
虽然方法的个数众多，但按照功能来划分的化，其实还是比较清晰的。所以接下来我们将只是摘选几个进行探究，毕竟如果只是傻傻得复制粘贴，这篇文章就毫无价值了。
- 首先具有鲜明特征的生命周期方法
init，clear。只要认识这两个单词的就能猜到这两个方法的作用以及调用时机。这两个方法的调用位置都是位于ActionHandler.handle中。 - 然后是为了简化AOP操作而提供的
enhance系类方法。该系列方法的底层实现相当简单，只是转而调度给了底层的Enhancer类。 - 然后一系列的
getXxx方法。关于这些方法就不具体展开了，它们其实还可以被细分为好几种，有获取前端传递来的参数的，获取Cookie的，获取Session的，获取上传的文件的等等。有兴趣的读者挨个测试一下就能熟练运用了。 - 接着是一系列的
renderXxx方法。一般情况下，我们在自定义的Action逻辑的最后都会调用其中的一个方法。而且jfinal也作了类似的推荐。而且jfinal还专门提供了renderNull来针对框架使用者自己处理了返回值的情况，此时框架使用者只需要显式调用一次renderNull即可。这里我们捎带脚地讨论一点细节，观察底层实现代码我们可以发现：renderXxx系列方法其实就在给全局字段render赋值，而且jfinal似乎比较偏好这种模式。被赋值完毕的render最终会通过getRender被外界取走调用。 - 最后稍微提一下Controller中定义的Tokjen相关的方法
createToken / validateToken。这两个方法是涉及到重复性提交问题而存在的。具体的可以参见下下面这篇问答——相关问题
3. 继承链
jfinal在整个框架层面， 都只有一个Controller抽象类，剩下的都是交给框架使用者自己去扩展。
另外在3.3版本里 提供了 ControllerFactory 扩展，外界可以通过扩展提供自己的Controller实例化逻辑，以支持用户接管 controller 生命周期。
4. 补充
- 初次接触到
Controller源码的可能会好奇为什么其内部会有一个action字段。在一般的印象中不应该是这样的，一般应该是action中包含一个Controller。这是因为jfinal借鉴了struts2的思路，对于每一个请求都都构建一个全新的Controller实例，所以基于此Controller中包含Action的字段也就可以理解了。这样也确保了Controller是线程安全的。 - 另外关于上面已经提及的
renderXxx系列方法。其被赋值的render字段的使用，这里稍微深入一些。在ActionHandler的handle方法中，在new Invocation(action, controller).invoke();之后，紧接着的就是Render render = controller.getRender();；正是在这里， 在Invocation.invoke中最终调用自定义Action之后，jfinal框架将赋值完毕的render字段值取走。
5. 总结
1.Controller类在jfina框架的体系里有着举足轻重的地位。 jfinal 将该类放在com.jfinal.core中，由此可见一斑。
2. 框架使用者，通过继承自Controller就能享受到jfinal提供的以上这些默认功能，而且我们可以感受到，在普通的项目开发中，常用的也就这么些。