我看到网站的许多MVC实现都有一个单入口点，例如index.php文件，然后解析URL以确定要运行哪个控制器。这对我来说似乎很奇怪，因为它涉及到必须使用Apache重写来重写URL，并且有足够的页面使单个文件变得膨胀。
为什么不将各个页面作为控制器呢？我的意思是，如果您的网站上有一个列出所有已注册成员的页面，则用户导航到的members.php页面将成为成员的控制者。这个php文件将从成员模型中查询数据库中的成员列表，并将其传递给成员视图。
我可能会遗漏一些东西，因为我最近才发现MVC，但这个问题一直困扰着我。难道这种设计不是优选的，因为不是有一个膨胀的入口文件，所有页面都不直观地调用特定页面的模型和视图被包含，封装，并从其各自的页面调用？
答案 0 :(得分：6)
根据我的经验，拥有单一入口点有几个臭名昭着的优势：
它简化了集中式任务，例如资源加载（连接到db或memcache服务器，记录执行时间，会话处理等）。如果要添加或删除集中任务，只需更改单个文件，即index.php。
在PHP中解析URL会使“虚拟URL”与Web服务器上的物理文件布局分离。这意味着您可以轻松更改URL系统（例如，用于SEO目的或用于站点国际化），而无需实际更改服务器中脚本的位置。
然而，有时候有一个单一的入口点可能会浪费服务器资源。这显然适用于静态内容，但是当您有一组具有非常特定目的的请求时，只需要一小部分资源（例如，他们可能不需要数据库访问）。那么你应该考虑有多个入口点。我已经为我正在处理的网站做了这个。它具有所有“标准”动态内容的入口点和另一个用于调用公共API的入口点，这需要更少的资源并具有完全不同的URL系统。
最后一点说明：如果网站实施得很好，你的index.php就不必变得臃肿：）
答案 1 :(得分：3)
所有关于DRY，如果你有许多处理请求的php文件，你将有重复的代码。这只会造成维护噩梦。
查看CakePHP的“主要”索引页面https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php
无论应用程序有多大，我都不需要修改它。那怎么会臃肿呢？
答案 2 :(得分：1)
当使用MVC框架时直接深入链接到控制器时，它取消了实现控制器插件或过滤器的可能性，具体取决于您使用的框架。具有单一入口点可以标准化应用程序和模块的引导，并在访问控制器之前执行先前提到的插件。
Zend Framework也以路由的形式使用自己的URL重写。在使用Zend Framework的应用程序中，我使用的.htaccess文件可能包含6行重写和条件。
答案 3 :(得分：0)
单个入口点肯定有其优点，但是您可以从处理数据库连接，会话等的每个页面顶部的中央所需文件中获得相同的好处。它不会膨胀，它符合DRY原则（除了那个需要行），它分离逻辑和表示，如果你改变文件位置，一个简单的搜索和替换将修复它。
我已经使用了两者，我不能说一个人的目的是为了我的目的更好或更差。
答案 4 :(得分：0)
软件工程师正在影响单点入口范式。 “为什么不让单个页面成为控制器？”
从某种意义上说，单个页面已经是 class B;
class A {
private:
int v;
friend class B;
};
class B {
private:
B array[5]; //B has access to A's vars
};
。
Controllers 作为要捕获的首要异常。通过集中代码，您只需在一处进行更改！确实，集中式 PHP 将至少使用一个 require 语句（用于加载自动加载器代码），但即使您有许多 require 语句，它们也会在一个文件中，即 index.php（不会分散到一个星系中）文件根目录下的文件）。
Throwable 或 $_SERVER 中的值？那么你不妨将它集中起来。底线是这个。您在每个页面上执行的操作越多，您就越有理由将代码集中起来。
请注意，这种思维方式会导致将您的网站视为 Web 应用程序。从 Web 应用程序的角度来看，单点入口是合理的，因为一次解决的问题应该只需要在一个地方进行修改。