【发布时间】：2010-10-06 21:50:02
【问题描述】：
我目前为我的所有网站设计每个页面都有一个文件，然后包括页眉、页脚等常见元素。但是，我注意到许多框架和 CMS 都使用前端控制器模式。
使用前端控制器有哪些优点和缺点？该模式是否只是在框架和 CMS 中使用，因为不知道最终系统中将存在哪些页面？
【问题讨论】：
标签： design-patterns front-controller
【发布时间】：2010-10-06 21:50:02
【问题描述】：
Srikanth 有一个很好的答案。不过，我想详细说明替代方案。假设您有这个简单的 URL 层次结构：
/画廊 /博客 /管理员/登录 /管理员/新帖子如果这是使用页面控制器（例如 PHP）实现的，gallery.php 和 blog.php 都需要在开头（或附近）包含一些 common.php。但是，login.php 和newpost.php 都可能包含admin-common.php，它本身会引入“common.php”并执行“/admin/”特定设置，例如验证用户是否经过身份验证。
一般来说，如果你有一个 URL 层次结构，它最终看起来很像对象继承树。除了不使用语言级继承之外，您还继承了所包含的任何 foo-common.php 的环境。
我无法想象前端控制器如何提高可测试性，最终，无论实施如何，都需要来自自动化 HTTP 用户代理的完全相同的测试。
页面控制器的一个主要缺点是它确实使您的 Web 应用程序依赖于其托管环境。它还迫使您的开发人员“看到”与最终用户相同的结构，但我认为这是一件好事，考虑到我看到的具有绝对糟糕 URL 的网站的数量。
【讨论】：
这些是我从不使用前端控制器的原因。
- 我们有一个完美的前线 控制器称为网络浏览器。
- 每个 http 请求都是唯一且独立的，应该这样对待。
- 无法使用前端控制器扩展应用程序。
- 如果您将 Web 应用程序分解为松散耦合的小模块，则更容易测试单元/模块（例如，您无需测试架构和控制器）。
- 如果您唯一地处理单个请求，性能会更好。
前面的控制器模式根本不适合恕我直言。 构建应用程序的方式与 UNIX 大致相同，将一个较大的问题分解为执行一项任务的小单元，并且非常好地完成该任务。大多数框架都在推动开发人员使用前端控制器，他们完全错了。
【讨论】：
-
"无法使用前端控制器扩展应用程序。"这似乎很明显，因为必须将 URI 映射到类的方式，但是一旦考虑到数据访问和 I/O，原始 PHP 的性能会好多少？
-
@FredWilson 我关于扩展的观点是，如果您使用前端控制器，则意味着每个请求都会到达所有服务器上的单个入口点。如果应用程序的每个部分都有单独的入口点，则可以单独扩展每个部分，例如。邮件应用程序：您可以为 read-email.php 分配比 send-email.php 更多的服务器，因为人们通常会比发送更频繁地阅读电子邮件。这不能通过前端控制器来实现，您必须一起扩展所有可能性。
-
此信息是否仍然相关？像 Laravel、Zend Framework、Expressive 和许多其他框架似乎只使用前端控制器模式，直接到文件的路由被称为“过时”.. (stackoverflow.com/questions/48079853/…)
改写Wikipedia article on Front Controller：
一句话——你用它来避免重复。
更详细一点：
前端控制器“为处理请求提供了一个集中的入口点。”假设您的网络应用的前端控制器是index.php。
这个脚本 index.php 将处理整个应用程序或周围框架共有的所有任务，例如 会话处理、缓存、输入过滤。根据给定的输入，它将实例化更多对象并调用方法来处理特定任务。
前端控制器的替代方案是单独的脚本，如 login.php 和 order.php，每个脚本都包含所有任务共有的代码或对象。这需要在每个脚本中重复包含代码，但也可能为脚本的特定需求留出更多空间。
【讨论】：
使用前端控制器的一个优点是它的可测试性。如果您使用 TDD，那么测试控制器要比请求许多不同的网站容易得多。
稍后添加： Tom：我的意思是它更可测试的原因是因为您通常将 webhandler 实现为类而不是服务器页面。然后你可以直接在类上做很多测试。
【讨论】：