为什么应该为网站MVC需要单点输入？

Question

我看到许多网站的MVC实现有一个单一入口点，如index.php文件，然后解析URL以确定要运行哪个控制器。这对我来说似乎很奇怪，因为它涉及到必须使用Apache重写来重写URL，并且有足够的页面使单个文件变得臃肿。

为什么不相反只是让单个页面成为控制器？我的意思是，如果您的网站上有一个列出所有注册会员的页面，那么页面导航的members.php将成为会员的控制器。这个php文件将查询成员模型中的数据库成员列表，并将其传递给成员视图。

我可能会错过一些东西，因为我最近才发现MVC，但这个问题一直在困扰着我。这种设计不是最好的，因为它没有一个臃肿的入口文件，所有的页面都不直观地调用模型，并且包含，封装并从各自的页面调用特定页面的视图？

Answer 1

从我的经验，具有单入口点有几个臭名昭著的优点：

它简化集中的任务，如资源加载（连接到数据库或一个内存缓存服务器，日志执行时间，会话处理等）。如果你想添加或删除一个集中式任务，你只需要改变一个单独的文件，这是index.php。

在PHP中解析URL会使“虚拟URL”与Web服务器上的物理文件布局解耦。这意味着您可以轻松更改您的URL系统（例如，用于SEO目的或站点国际化），而无需实际更改服务器中脚本的位置。

但是，有时有一个单入口点可能会浪费服务器资源。这显然适用于静态内容，但是当您有一组具有特定目的的请求时，只需要一小部分的resorces（也许它们不需要DB访问）。那么你应该考虑有多个入口点。我为我正在工作的网站做了这些工作。它具有所有“标准”动态内容的入口点，另一个用于调用公共API的入口点，这需要更少的资源并且具有完全不同的URL系统。

而且最后要注意的：如果该网站是很好实现的，您的index.php没有成为必然臃肿:)

Answer 2

它全部都是关于DRY，如果你有很多PHP文件处理请求，你将有重复的代码。这只是一个维护噩梦。

看一看为CakePHP的“主”索引页，https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php

不管应用程序有多大得到，我从来没有需要修改。所以它怎么会变得臃肿？

Answer 3

当使用MVC框架时直接deeplinking到控制器它消除的可能性根据您使用的框架实施控制器插件或过滤器。在访问控制器之前，拥有单一入口点将标准化应用程序和模块的引导程序，并执行前面提到的插件。

此外，Zend Framework使用自己的URL重写形式的路由。在使用Zend Framework的应用程序中，我工作的是可能有6行重写条件和条件的.htaccess文件。

Answer 4

单一入口点固然有其优点，但你可以在一个处理数据库连接，会话等，这是不臃肿，它符合每一个页面的顶部得到相当多从中央要求的文件相同的利益干燥的原则（除了那个需要一行），它分离逻辑和演示文稿，如果你改变文件位置，一个简单的搜索和替换将修复它。

我已经使用了两个，我不能说我的目的是更好或更糟。