前端控制器模式之一二

4年以前，当我还在一种叫ASP的东西上工作的时候，我整天为两个问题头疼不已：一是如何将分散的页面控制整合起来。解释型的服务器端脚本，每个页面都有接收和处理请求的能力。这样以每个页面作为独立的单元来处理请求让人感觉粒度太小，分散又不爽。二是如何减少重复代码。脚本语言里处理重复代码的灵丹妙药是include。每个页面里都可以include header，footer，session checker，屡试不爽。但有一次我很不幸，我要改一下header的名字……
后来投靠了java，用了struts，豁然开朗，就像天空中飘下来几个大字：前端控制器。在这几个字的怀里缠绵已久，回望脚本语言林林总总，处处鲜花烂漫。

前端控制器在《J2EE核心模式》一书中已经完整的定义过了了，不再复述。下面只是记一下自己在工作中遇到过的前端控制器模式的实例：
1. 解释型脚本的前端控制器的实现：近期接触了一个php项目，打开看了它的index.php，顿时感觉醍醐灌顶，赞叹作者思想精妙不已，一个小小的页面里面做了控制分发和页面Layout处理。用户所有的请求都发送给index.php页面，然后后面加上几个参数，如action和event。该系统个php文件的关系是通过命名约束来处理的。比如如果action=XXX，那么会有一个XXX.class.php，一个XXX.page.template.php，还有相关的footer，header，form，content之类的页面对应文件。当index页面接到请求的时候通过action名字匹配，利用万能的include将对应的class.php加载进来，作为对action进行处理的command使用。当command处理完以后，然后再把对应的page.template，footer，header，content加载进来，然后根据event进行处理。所有动作完成后，把组装好的页面返回给用户。一次控制分发和页面处理就完成了。一个百行的index.php代码就完成了一个完整的前端控制器，整个框架不可谓不轻啊。脚本的灵活性让我这个整天活在java的xml配置文件里的人好生羡慕啊。
更加完整的解释型前端控制器：用过一个月的ColdFusion，解释型的标签式语言。March II是这个平台上最流行的MVC框架之一。这个框架和struts非常相似，一个配置核心的XML文件。不过解释型脚本的问题在于它们的最小粒度永远都是独立的一个页面。这个框架接收用户请求的还是那个index.cfm文件。这个文件会将请求转给March II的核心文件，并且在第一次被调用的时候会初始化一个应用级的变量，来保存系统xml里的信息。然后通过index.cfm后面的参数匹配来处理action（MarchII叫它listener），event之类的东西。这个系统在实现信息包装、控制分发和页面处理的同时，还实现了拦截器的功能。在处理action的listener前面加了一个叫filter的东西来处理，来进行过滤用户信息。整体来说这个框架算是一个比较完整的MVC框架。也是我见过的比较完整的解释型脚本的框架。

2.JAVA EE里的前端控制器：Strut1和Struts2里面的做法算是比较经典的两种前端控制器。由于JAVA EE中对处理用户请求的单元进行了重新定义，类型更丰富，比如Filter和Servlet。而配置的映射机制使接收用户请求的粒度变得很有弹性。struts1里面使用Servlet作为前端控制器，来实现用户请求的封装，控制分发，和结果返回处理。struts2 对struts1这方面最大的改进莫过于使用Filter来作为前端控制器。由于Filter本身就是非常典型的Chain模式，请求运转与Filter之中，就是行走于一个链中，而且filter接收和处理请求位于比Servlet更靠前的位置，这使我们在基于它进行开发时，活动余地更大，更增强了我们对request和response的控制，也提供了一种框架内更便捷的拦截器（或者叫子链）实现方式。关于Struts1和struts2，想必大家都已经烂熟于心了，也没必要重复了。

3. 令人眼前一亮的奇妙想法：和同事交流前端控制器模式的心得，他说了一个让人神清气爽的例子，也是php的。他维护的那个项目有一个要求比较安全的模块。刚开始他始终找不到驱动这个模块的核心在哪里。用户请求的地址总是找不到相匹配的php文件，也没有找到代码里有能处理这些请求分发的地方。找来找去，突然发现这个系统的前端控制器是一个大家天天都会见的页面：HTTP 404错误页面。因为每一个找不到对应资源的请求都会来到这里，所以他们在这里做了请求解析、控制分发的处理。看到如此巧妙的东西，实在是惊叹设计人员的脑子。且不说这种做法的好与坏，它至少将核心处理的代码隐藏到了一个应用级别以外的地方。大家大笑以后，想想这也是个很好的trick啊。

asp当年，设计上是和isapi,activex共同来实现网站的。可是由于isapi,com门槛太高，以至于大部分开发人员只会使用asp.....不能不说是这种架构的悲哀....

在iis中，isapi filter作为前端控制，isapi extention/com负责主要逻辑，ado(也是个com)负责数据层，asp负责view层。
想明白，其实现在的所谓新技术\新框架也只是在这种结构上做了少许改动而已....看山还是山啊～～～～

使用ISAPI的话，在很大程度上限制了脚本型语言的轻便快捷。而且当年铺天盖地的ASP书籍上很少有提ISAPI的，导致ISAPI在普及方面遇到了很大的瓶颈。而且当年咱们搞个PWP，IIS之类的就能在自己机器上建起来ASP环境，如果用COM的话，又是编译，又是注册表的，这种复杂度无意中又拖了COM的后腿

其实当年微软是想用COM一统江湖的，但是COM本身的一些硬伤，使COM这个东西曲高和寡，不过也有好处，就是催生.NET这种被称作COM++的东西

现在看来旧的ASP设计还蛮先进的！
不知Asp in JScript＋一堆可用com组件之配搭，在Ajax流行的情况下，有没有柳暗花明又一村的机会！？
起码这样说的是前后台同一种语言，起码支持ASP的主机的一年才一百块...

我敢保证100块一年的ASP主机是不会让你注册自己的COM组件的。
ASP是已经行将就木，但COM/COM+的架构设计和思想还是会继续发展下去，毕竟这是微软在企业级应用方面的立足点，微软已经把它们升级为CLR和.NET 企业服务。

我觉得 j2ee里的前端控制器只是作为初始访问点进行集中访问，
而应用控制器才是进行操作与视图管理(调用action之类的)。

我承认我最后的一句是多余的
我所表达的。。。只是

前端控制器模式的参与者有控制器，分发者，视图，助手等，控制器是用户请求的集结点，分发者请求匹配和分发，助手处理数据和辅助视图。
我不太明白你说的那个应用控制器是指哪个，位于什么位置。我感觉你说的有点像分发者



也可能我在这里说的概念有些混乱。我说前端控制器模式的时候是指上述元素构成的一种表现层的处理模式，而我说前端控制器的时候是单指这种模式里的控制器部分。

前端控制器的概念，
我也是从asp时代就略有了解，总体上来说就是一个分发，给用户一个集中的访问点，尽量的减少重复代码。
楼主说的《J2EE核心模式》 我也有看过，里面有简单介绍一下struts的原理，我只记得有2个概念，
一个叫 前端控制器，一个叫 应用控制器。

前端控制器 只是一个统一访问的servlet，struts中就是ActionServlet，ActionServlet接受到http请求之后都统一调用process()方法，process()通过调用 应用控制器进行视图分发以及操作流程控制(根据action返回的ActionForward对象)。

书中描述的 前端控制器 我感觉就是很薄的一层,很简单的一个servlet,楼主可能是说这2个组合在一起的吧?

理解了就好了，千万别被名词解释绕进去...

前端控制器，就是在实际处理模块之前的控制器。它也不是什么专有名词。也有后端控制器，比如特殊信息的屏蔽就可以用后端控制器来做。他们的实现方法那也是多种多样，filter,servlet,AOP等等方式都能实现。

再讲讲asp,其实在iis中也仅仅是个由isapi实现的脚本解释器而已。其实可以很容易的自己写个isapi去调用jvm实现jsp的脚本解析，事实上，asp.net也是这么做的（用isapi调用clr实现.net中间代码的解析）。

前面说到的asp in js+ajax去实现网站在现在这个虚拟主机的大环境下可能会有一定的生命力，不过恐怕很难有第二春。以后的虚拟主机绝对不会是简单架个操作系统就往外卖服务的了。SAAS之类的服务很可能就是现有虚拟主机的替代品。技术上来说，ajax也不应该会是一个长命的技术，肯定需要出现新的技术来取代它，事实上，ajax还是太不方便了。

跑题了，跑题了.....人老了，话就多了啊....