10

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

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

4

4 回答 4

11

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 的网站的数量。

于 2009-02-11T13:51:25.887 回答
9

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

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

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

于 2010-12-06T18:29:53.210 回答
8

改写关于 Front Controller 的 Wikipedia 文章：

一句话—​​—你用它来避免重复。

稍微详细一点：

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

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

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

于 2009-02-11T13:37:35.983 回答
1

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

稍后添加： Tom：我的意思是它更可测试的原因是因为您通常将 webhandler 实现为类而不是服务器页面。然后你可以直接在课堂上做很多测试。

于 2009-02-11T13:36:26.530 回答