为什么网站的 MVC 需要单点入口？
我看到许多网站的 MVC 实现都有一个单入口点，例如 index.php 文件，然后解析 URL 以确定要运行哪个控制器。这对我来说似乎很奇怪，因为它涉及到必须使用 Apache 重写来重写 URL，并且页面足够多，单个文件会变得臃肿。
为什么不直接让各个页面作为控制器呢？我的意思是，如果您的网站上有一个页面列出了所有注册会员，那么用户导航到的 members.php 页面将成为会员的控制器。该 php 文件将从数据库中查询成员模型以获取成员列表，并将其传递到成员视图。
我可能错过了一些东西，因为我最近才发现 MVC，但这个问题一直困扰着我。这种设计不是更可取吗？因为所有页面都不直观地调用特定页面的模型和视图，而不是拥有一个臃肿的入口文件，并且从其各自的页面中包含、封装和调用？
I see many MVC implementations for websites have a single-entry point such as an index.php file and then parses the URL to determine which controller to run. This seems rather odd to me because it involves having to rewrite the URL using Apache rewrites and with enough pages that single file will become bloated.
Why not instead just to have the individual pages be the controllers? What I mean is if you have a page on your site that lists all the registered members then the members.php page users navigate to will be the controller for the members. This php file will query the members model for the list of members from the database and pass it in to the members view.
I might be missing something because I have only recently discovered MVC but this one issue has been bugging me. Wouldn't this kind of design be preferable because instead of having one bloated entry-file that all pages unintuitively call the models and views for a specific page are contained, encapsulated, and called from its respective page?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据我的经验，单入口点有几个众所周知的优点：
它简化了集中任务，例如资源加载（连接到数据库或内存缓存服务器、记录执行时间、会话处理等）。如果你想添加或删除一个集中任务，你只需要更改一个文件，即index.php。
在 PHP 中解析 URL 可以使“虚拟 URL”与 Web 服务器上的物理文件布局解耦。这意味着您可以轻松更改 URL 系统（例如，出于 SEO 目的或网站国际化），而无需实际更改脚本在服务器中的位置。
然而，有时拥有单一入口点可能会浪费服务器资源。这显然适用于静态内容，而且当您有一组具有非常特定目的的请求并且只需要很少的资源集（例如，也许它们不需要数据库访问权限）时。那么您应该考虑拥有多个入口点。我已经为我正在开发的网站做到了这一点。它有一个用于所有“标准”动态内容的入口点，还有一个用于调用公共 API 的入口点，后者需要的资源少得多，并且具有完全不同的 URL 系统。
最后一点：如果网站实施良好，您的index.php 不一定会变得臃肿:)
From my experience, having a single-entry point has a couple of notorious advantages:
It eases centralized tasks such as resource loading (connecting to the db or to a memcache server, logging execution times, session handling, etc). If you want to add or remove a centralized task, you just have to change a singe file, which is the index.php.
Parsing the URL in PHP makes the "virtual URL" decoupled from the physical file layout on your webserver. That means that you can easily change your URL system (for example, for SEO purposes, or for site internationalization) without having to actually change the location of your scripts in the server.
However, sometimes having a singe-entry point can be a waste of server resouces. That applies obviously to static content, but also when you have a set of requests that have a very specific purpose and just need a very little set of your resorces (maybe they don't need DB access for instance). Then you should consider having more than one entry point. I have done that for the site I am working on. It has an entry point for all the "standard" dynamic contents and another one for the calls to the public API, which need much less resources and have a completely different URL system.
And a final note: if the site is well-implemented, your index.php doesn't have to become necessarily bloated :)
这都是关于 DRY 的，如果你有很多处理请求的 php 文件，你就会有重复的代码。这只会造成维护噩梦。
看一下 CakePHP 的“主”索引页面，https： //github.com/cakephp/cakephp/blob/master/app/webroot/index.php
无论应用程序有多大，我都不需要修改它。那么怎么会肿呢？
it is all about being DRY, if you have many php files handling requests you will have duplicated code. That just makes for a maintenance nightmare.
Have a look at the 'main' index page for CakePHP, https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php
no matter how big the app gets, i have never needed to modify that. so how can it get bloated?
当使用 MVC 框架直接深度链接到控制器时，它消除了实现控制器插件或过滤器的可能性，具体取决于您使用的框架。拥有单点入口可以标准化应用程序和模块的引导，并在访问控制器之前执行前面提到的插件。
Zend Framework 也以路由的形式使用它自己的 URL 重写。在我工作的使用 Zend Framework 的应用程序中，有一个 .htaccess 文件，其中可能有 6 行重写规则和条件。
When deeplinking directly into the controllers when using an MVC framework it eliminates the possibility of implementing controller plugins or filters, depending on the framework you are using. Having a single point of entry standardizes the bootstrapping of the application and modules and executing previously mentioned plugins before a controller is accessed.
Also Zend Framework uses its own URL rewriting in the form of Routing. In the applications that use Zend Framework I work on have an .htaccess file of maybe 6 lines of rewriterules and conditions.
单个入口点当然有其优点，但是您可以从每个页面顶部处理数据库连接、会话等的中央必需文件中获得几乎相同的好处。它并不臃肿，它符合 DRY 原则（除了对于那个 require 行），它将逻辑和表示分开，如果您更改文件位置，简单的搜索和替换即可修复它。
我两种都用过，对于我的目的来说，我不能说其中一种明显更好或更差。
A single entry point certainly has its advantages, but you can get pretty much the same benefit from a central required file at the top of every single page that handles database connections, sessions, etc. It's not bloated, it conforms to DRY principles (except for that one require line), it seperates logic and presentation and if you change file locations, a simple search and replace will fix it.
I've used both and I can't say one is drastically better or worse for my purposes.
软件工程师正在影响单点入口范例。 “为什么不直接让各个页面成为控制器呢？”
从某种意义上说，各个页面已经是
控制器了。Throwable作为要捕获的首要异常。通过集中代码，您只需在一处进行更改！诚然，集中式 PHP 将至少使用一个 require 语句（来加载自动加载器代码），但即使您有许多 require 语句，它们也将位于一个文件中，index.php（不会分布在一系列文件中）在文档根目录下）。
$_SERVER或filter_input_array()中的值？那么你不妨将其集中化。底线是这样的。您在每个页面上执行的操作越多，您就越有充分的理由集中该代码。
请注意，这种思维方式会导致人们将网站视为 Web 应用程序。从 Web 应用程序的角度来看，单点入口是合理的，因为解决一次的问题只需要在一个地方进行修改。
Software engineers are influencing the single point of entry paradigm. "Why not instead just to have the individual pages be the controllers?"
Individual pages are already
Controllers, in a sense.Throwableas the top exception to catch. By centralizing code, you only need to make changes in one place!True, the centralized PHP will use at least one require statement (to load the autoloader code), but even if you have many require statements they will all be in one file, the index.php (not spread out over a galaxy of files on under the document root).
$_SERVERorfilter_input_array()? Then you might as well centralize that.The bottom line is this. The more you do on every page, the more you have a good reason to centralize that code.
Note, that this way of thinking leads one down the path of looking at your website as a web application. From the web application perspective, a single point of entry is justifiable because a problem solved once should only need to be modified in one place.