使用Front Controller模式有哪些优缺点？

Question

我目前使用每个页面的文件设计我的所有网站，然后包含常见元素，如页眉，页脚等。但是，我注意到许多框架和CMS都使用Front Controller模式。

使用前置控制器有哪些优缺点？模式是否仅仅用在框架和CMS中，因为不知道哪个页面将存在于最终系统中？

Answer 1

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 /'特定设置，例如验证用户是否经过身份验证。< / p>

通常，如果您有一个URL层次结构，它最终看起来很像对象继承树。除了使用语言级继承之外，您将继承您所包含的foo-common.php的环境。

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

页面控制器的一个主要缺点是它确实使您的Web应用程序依赖于其托管环境。它还会迫使您的开发人员“看到”与最终用户相同的结构，但我认为这是一件好事，考虑到我看到的网站数量绝对是非常糟糕的网址。

Answer 2

这就是我永远不会使用前置控制器的原因。

• 我们有一个非常好的前线 控制器称为网络浏览器。
• 每个http请求都是唯一且独立的，应该这样对待。
• 无法使用前端控制器扩展应用程序。
• 如果您将Web应用程序分解为松散耦合的小模块，则更容易测试单元/模块（例如，您不测试体系结构以及控制器）。
• 如果您唯一地处理单个请求，性能会更好。

前控制器模式根本不适合恕我直言。 构建应用程序的方式与UNIX大致相同，将较大的问题分解为执行一项任务的小型单元，并且可以很好地完成该任务。大多数框架都在推动开发人员使用前端控制器，这些都是错误的。

Answer 3

改述Wikipedia article on Front Controller：

在句子中 - 使用它来避免重复。

更详细一点：

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

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

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

Answer 4

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

稍后添加： Tom：我之所以认为它更可测试是因为你通常将webhandlers实现为类而不是服务器页面。然后你可以在课程上直接做很多tetst。