前段控制器是邪恶的吗？

所谓前端控制器（FrontController），是指一个请求运行的公共起点，并且在这里决定下一步执行什么。多数PHP框架里都实现了它。统一进行权限限制，会话管理等等公共操作，并且进而通过一个类似路由的装置，把请求委派给一个具体的命令对象来执行。实现方式上，前端控制器通常是以一个名为index.php的文件为载体，通过重写规则把请求都转发到这个文件上，如CakePHP在Apache上的设置：








RewriteEngine On


RewriteCond %{REQUEST_FILENAME} !-d


RewriteCond %{REQUEST_FILENAME} !-f


RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]








不过老话说，物极必反，随着前端控制器使用的泛滥，越来越多的人开始质疑PHP开发是否有必要使用前端控制器。这里以PHP之父Rasmus Lerdorf的影响最大，早些时候，他在Simple is Hard里陈述了如果想开发出有扩展性的Web应用，必须保证架构是Share-nothing Architecture：





Share-nothing Architecture


* Like HTTP, each request is distinct


* Shared data is pushed down to the data-store layer


* Avoid front controllers








Rasmus Lerdorf的看法：


在Rasmus Lerdorf看来，想要让一个网站具有良好的扩展性其实是非常简单的，只需将网站应用分成若干个独立小程序，前端透过API提供服务，后端是应用程序引擎，这样做自然会有扩展性。因为应用的每一个部分，都有不同等级的使用方式，需要有不同的扩充程度，需要不同的机制来处理。以开发雅虎电子邮件而言，是要开发一个地址服务程序、一个读信服务、一个送信服务，而送信程序完全和读信程序无关。以雅虎的规模而言，需要让这些工作完全分离，才有扩充性。这里的关键是你必须建立分离、模块化的独立端点，而不是全部放在同一个大篮子里。大多数现今开发框架，都使用了前端控制器，每一次浏览器发出请求时，就会调用这个前端控制器，再由前端控制器来分辨，使用者想要执行哪一支程序。这样做，一点意义都没有。在浏览器层次，程序完全能知道用户想要做什么事情，例如使用者只是要读信，程序就不用再把需求送到服务器，让服务器判断使用者要读信还是送信。将这类决策工作拉出浏览器，由服务器处理，就会浪费大量服务器资源，来处理那些对用户没有实际功用的工作。







我的看法：
我绝对相信Rasmus Lerdorf对于系统可扩展性的论述。但是我觉得他对于前端控制器合理性的判断太过武断。诚然，在浏览器的层面就完成了所有路由的工作有很好的可扩展性，但是在不同的请求里都进行权限限制，会话管理等等公共操作也变得重复了。而且，Rasmus Lerdorf对于前段控制器的论述是建立在一个假设条件上的：网站仅有一个前端控制器，并且仅运行在一台服务器上，所有的请求都要经由这台服务器再进行分发。如果真是这样，那么前端控制器必然会引起单点瓶颈，但事实上我们在实际使用前端控制器的时候，完全可以把代码拷贝到若干台服务器之上，请求均匀的分发到这些服务器上，此时的前端控制器只是程序逻辑上的单点，在物理架构上，是不存在瓶颈的，对扩展性没有影响。而且，系统里是可以有多个前端控制器的，比如说一个网站里可以有文章系统前端控制器，论坛系统前端控制器，用户系统前端控制器，这样压力自然就得以分散。当然，一不留神还是会遭遇一些前端控制的使用障碍，比如说路由无限扩张的问题：通常，使用前端控制器的时候，需要通过路由设定来映射URL和Action的关系，随着系统的膨胀，路由设定的内容会越来越多，每当一个请求过来的时候，都要从头解析路由设定以找出符合本次URL映射的Action，如果路由设定内容很多的话，这无疑是个巨大的负担，想要规避这个问题也没有太好的方法，只能是尽可能精简的使用自定义路由的功能。

总结：
牢记Rasmus Lerdorf的教诲是有意义的，但前端控制器并不邪恶，在了解它的优缺点后，合理的使用，既能保持程序的美感，又不丧失架构的扩展性。