Design patterns 使用前控制器模式的优点和缺点是什么？

我目前设计的所有网站，每个页面都有一个文件，然后包括页眉、页脚等常用元素。然而，我注意到许多框架和CMS使用前端控制器模式

---

使用前端控制器的优点和缺点是什么？该模式仅仅用于框架和CMS中，是因为不知道最终系统中将存在哪些页面吗？

使用前端控制器的一个优点是其可测试性。如果您使用TDD，那么测试一个控制器要比请求许多不同的网站容易得多

稍后添加： Tom：我的意思是它更易于测试的一个原因是，您通常将WebHandler实现为类而不是服务器页面。然后，您可以直接在类上执行大量tetst。

重新表述：

在一句话中--你用它来避免重复

更详细一点：

前端控制器“为处理请求提供了一个集中的入口点。”让我们假设web应用程序的前端控制器是

index.php

这个脚本index.php将处理整个应用程序或框架所共有的所有任务，如会话处理、缓存、输入过滤。根据给定的输入，它将实例化更多的对象并调用方法来处理特定的任务

---

前端控制器的替代方案是单独的脚本，如login.php和order.php，每个脚本都包含所有任务通用的代码或对象。这将需要在每个脚本中重复包含代码，但也可能为脚本的特定需求留出更多空间。

Srikanth有一个很好的答案。不过，我想详细说明一下替代方案。假设您有以下简单的URL层次结构：

/gallery /blog /admin/login /admin/newpost /画廊 /博客 /管理员/登录 /行政/新邮政 如果这是通过页面控制器（例如PHP）实现的，那么

gallery.PHP

和

blog.PHP

都需要在开头（或附近）包含一些

common.PHP

。但是，

login.php

和

newpost.php

都可能包含

admin common.php

，它本身会拉入“common.php”并进行“/admin/”特定的设置，比如验证用户是否经过身份验证

一般来说，如果你有一个URL的层次结构，它最终看起来很像对象继承树。除了不使用语言级继承之外，您继承的是您包含的任何

foo common.php

的环境

我无法想象前端控制器是如何提高可测试性的，最终，不管实现如何，都需要来自自动HTTP用户代理的完全相同的测试

---

页面控制器的一个主要缺点是它确实使您的web应用程序依赖于其宿主环境。它还迫使开发人员“看到”与最终用户相同的结构，但是我认为这是一件好事，考虑到我所看到的网站具有绝对残暴URL的数量。

< P>这就是为什么我永远不会使用前端控制器的原因。

• 我们有一个非常好的战线 它的控制器称为web浏览器
• 每个http请求都是唯一的和独立的，因此应该这样对待

---

• 使用前端控制器无法扩展应用程序
• 如果您将web应用程序分解为松散耦合的小模块，那么就更容易测试单元/模块（例如，您不需要测试体系结构以及控制器）
• 如果单独处理单个请求，性能会更好

前控制器模式根本不适合IMHO。

---

构建应用程序的方式与UNIX大致相同，将较大的问题分解为执行一项任务的小单元，并将该任务做得非常好。大多数框架都在促使开发人员使用前端控制器，但他们完全错了。

“不可能使用前端控制器来扩展应用程序。”这似乎很明显，因为URI必须映射到类，但是，一旦考虑了数据访问和I/O，原始PHP的性能会有多好？@FredWilson我关于扩展的观点是，如果使用前端控制器，则意味着每个请求都会到达所有服务器上的单个入口点。如果应用程序的每个部分都有单独的入口点，则可以单独扩展每个部分，例如邮件应用程序：您可以为read-email.php分配比send-email.php更多的服务器，因为人们通常会比send更频繁地阅读电子邮件。这无法通过前端控制器实现，您必须将所有可能发生的情况一起缩放。此信息仍然相关吗？像Laravel、Zend Framework、Expressive等框架似乎只使用前端控制器模式，而直接到文件路由被称为“过时”。。()