有一个单一的网站入口点。令人不快的好的没有问题?

简而言之,拉斯穆斯的解释是错误的。

这表明人们对计算机的工作方式缺乏了解。使用的东西越多,它越接近CPU,因此 . 请注意,只有一个入口!=单点故障。但这一切都无关紧要,当人们说单点进入时,我们谈论的是应用程序,它是你逻辑的单点进入。

更不用说,没有一个中心入口点,或者总体上减少入口点的数量,在体系结构上是脑死亡。只要你想在每个入口点跨应用程序做一件事,猜猜有多少地方需要更改?在处理了一个每个页面都独立的应用程序后,它不得不改变,我向你保证,我们需要它。

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

不,单个入口点本身并不构成瓶颈。谷歌的首页点击率很高,但他们有很多服务器。

1. 鼓励分离“业务逻辑”(不管是什么)和模板/布局逻辑

2. 即时和(更重要的是) 访问将用于数据库查询、服务调用、数据模型等的对象。

对于像拉斯莫斯这样的人来说,这不值得在表演上大放异彩。他是一名C/C++程序员。对他来说,如果你想以一种高性能的方式分离业务逻辑,你可以编写一个PHP的C/C++扩展。

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

如果这不是你的环境,考虑前控制器框架能给你带来的生产力提高。 (likely) simple CRUD Application

我认为,与只有一个入口相比,您拥有的最大优势之一是安全性。如果在一个地方对输入进行检查和验证,则输入的所有输入不太可能损坏系统。

我认为从“一个文件”和“几个文件”的角度来讨论这个问题是一个很大的误解。

有人倾向于认为,因为入口点在一个文件中,所以我们只需要关注该文件中的代码——这是错误的。

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

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

那么,为什么我需要一个带有某种_detect_uri()函数的单一入口点,该函数需要调用其他几个函数,如strps()、substr()、strncmp()来清理、验证和拆分请求字符串,而我只需要使用几个入口点就可以一起消除这些代码?

看看uri.php中的CodeIgniters\u detect\u uri()函数。不要挑剔CodeIgniter,这只是一个例子。其他框架也这样做。

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

认为 这不是低效的原因是因为此文件不会根据控制器、操作甚至用户而更改。

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

需要 .

除此之外,我喜欢提供每个上下文的入口点,比如web(/soap)/console/。。。

另外,人们通常认为,由于有一个php页面,所以它是一个服务于所有请求的页面。有点像排队。

然而,有些框架可能有很多你不需要在入门脚本中进行的东西。有点像catchall来满足所有可能的场景,这可能会导致负载。

就我个人而言,我更喜欢多页,就像我混合oop和过程的方式一样。我喜欢老式的php。

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

拥有web服务器实际使用的目录结构可以使web服务器更简单,开发人员也更容易理解。对于web服务器来说,通过将url转换为文件传统上表示的位置来提供文件比将其重写为新url更简单。非前端控制器文件体系结构对开发人员来说可能更为明显,因为它们不是从一个臃肿的控制器开始处理所有事情,而是从一个文件/控制器开始,该文件/控制器更具体地针对他们需要开发的内容。