拥有一个网站的入口点。坏？好？没问题？

Question

这个问题源于观看Rasmus Lerdorf's talk from Drupalcon。这个问题和他的谈话与Drupal没什么特别的关系，顺便说一句......它只是在他们的骗局中给出的。我自己的问题也没有与PHP有任何关系。这是我一直很好奇的单一切入点。

现在似乎大多数框架都为您构建的任何内容提供单一入口点。在他的演讲中，拉斯穆斯提到他认为这很糟糕。在我看来，他在这个想法中是正确的。如果每个到达网站的人都通过相同的入口点进入，那么在流量到达某一点后不会陷入困境吗？允许人们直接访问网站中的特定点而不让他们的请求经历同一点是不是更有效率？但也许实际影响不是很糟糕？也许现代建筑可以处理它？也许你必须在规模上变得非常巨大才变得更值得考虑？我很好奇这个网站上的人们对这个问题的看法。

Answer 1

简而言之，Rasmus或解释是错误的。

这显示出对计算机如何工作的明显缺乏了解。使用的东西越多，越接近CPU的可能性就越大，因此更快。请注意，一个单一的入口点！=单点故障。但是，除此之外，当人们说单一入口点时，我们谈论的是应用程序，它是您逻辑的单一入口点。

更不用说它在建筑上已经死了，没有中心入口点，或者通常会减少入口点的数量。一旦你想在每个入口点对你的应用做一件事，猜猜需要改变多少个地方？处理了一个应用程序，每个页面都独立于它，它不得不改变，我保证，我们需要它。

Answer 2

重要的是，您通过负载平衡和声明性代码等方法使用支持可伸缩性的Web框架。

不，单一入口点本身并不构成瓶颈。谷歌的首页获得了很多热门，但他们有很多服务器。

所以答案是：没关系。

Answer 3

与软件开发中的任何内容一样，它取决于。 Rasmus对前端控制器风格框架的反对意见是你必须在每个请求上预先加载如此多的代码才能获得性能。这是100％的真实。即使你正在使用某种智能资源加载模块/对象/等，使用框架也是一种性能权衡。你可以获得性能，但作为回报，你会回来

1. 鼓励分离“业务逻辑”（无论是什么）和模板/布局逻辑

2. 即时和（更重要的）统一访问您将用于数据库查询，服务调用，数据模型等的对象。

对于像Rasmus这样的人来说，这不值得表现。他是一名C / C ++程序员。对他而言，如果您想以高性能的方式分离业务逻辑，那么您可以为PHP编写C / C ++扩展。

因此，如果您有一个环境和团队，您可以轻松地为PHP编写C / C ++扩展，并且您的上市时间与性能比是可以接受的，那么是的，抛弃您的前端控制器框架。

如果那不是您的环境，请考虑前端控制器框架可以为您的(likely) simple CRUD Application带来的工作效率提升。

Answer 4

我认为，只有一个入口点，您拥有的最大优势之一就是安全性。如果在一个地方检查和验证系统，所有进入的输入都不太可能破坏系统。

Answer 5

我认为从“一个文件”到“几个文件”这一点讨论这个问题是一个很大的误解。

人们倾向于认为因为入口点在一个文件中，所以我们必须关注的是那个文件中的代码 - 这是错误的。

所有流行的框架都有大量带有条目操作代码，解释代码和请求验证代码的文件。代码不在一个地方，而是在require / include语句的丛林中传播，根据所请求的内容和方式调用不同的类。

在这两种情况下，请求实际上都是由不同的文件处理的。

为什么我应该有一个带有某种_detect_uri（）函数的入口点，需要调用其他几个函数，比如strpos（），substr（），strncmp（）来清理，验证和拆分请求字符串，当我可以使用几个入口点一起消除所有代码？

查看URI.php中的CodeIgniters _detect_uri（）函数。不要选择CodeIgniter，这只是一个例子。其他框架也是如此。

您可以通过单个入口点以及多个入口点来实现MVC模式的目标。

Answer 6

这是我一开始的想法，但似乎并没有什么影响。毕竟，您的入口点（通常）只做了几件事：设置一些环境常量，包括引导加载程序，可选地捕获抛出的任何异常并调度前端控制器。我认为这个效率不高的原因是因为这个文件不会因控制器，动作甚至用户而改变。

但我觉得这很奇怪。我现在正在构建一个小型MVC框架，但它与我使用的大多数框架略有相反。我把控制器逻辑放在访问过的文件中。例如，index.php将包含IndexController及其操作。这种方法至少对我有用。

Answer 7

由于大多数php mvc框架使用某种url重写，或者至少在index.php之后解析任何内容，因此单个入口点需要。

除此之外，我想提供每个上下文的入口点，比如web（/ soap）/ console /...

Answer 8

添加，人们通常认为，因为有一个php页面，它是一个服务所有请求的单页。有点像排队。

需要注意的重要一点是，每个请求都会创建一个脚本实例，因此负载与同时访问两个不同页面的负载相同。所以，仍然是相同的负载。实际上。

但是，某些框架可能会包含很多你不需要在入口脚本中进行的操作。有点像一个catchall来满足所有可能的场景，这可能会导致负载。

就个人而言，我更喜欢多页，就像我混合oop和程序一样。我喜欢老学校的php。

Answer 9

使用前端控制器文件架构肯定存在缺点。正如Saem解释的那样，访问同一个文件通常对性能有利，但正如Alan Storm和Rasmus Lerdorf所解释的那样，尝试使代码处理多种情况（例如前端控制器试图处理对站点上每个“页面”的请求）导致臃肿和复杂的代码集合。对每个页面加载使用臃肿而复杂的代码集合可能被认为是不好的做法。

Saem认为前端控制器可以避免在多个位置编辑代码，但我认为在某些情况下，通过分离冗余可以更好地解决这个问题。

拥有Web服务器实际使用的目录结构可以使Web服务器更简单，对开发人员来说更明显。 Web服务器通过将url转换为传统上代表的位置来提供文件比将它们重写为新URL更简单。对于开发人员而言，非前端控制器文件架构可能更为明显，因为它们不是从处理所有内容的控制器开始，而是从文件/控制器开始，这些文件/控制器更加特定于他们需要开发的内容。