此問題源於觀看Rasmus Lerdorf's talk from Drupalcon。這個問題和他的演講與Drupal沒有任何特別的關係，順便說一下......它只是在他們的con中給出的。我自己的問題也沒有什麼特別與PHP做。一般而言，這是我很好奇的一個入口點。擁有一個網站的入口點。壞？好？沒問題？
現在，大多數框架似乎都爲您創建的任何內容提供了一個入口點。在他的講話中，拉斯穆斯提到他認爲這很糟糕。在我看來，他在這個想法中是正確的。如果每個人都通過同一個入口進入網站，那麼當流量達到某個點後，是不是會出現問題？讓人們直接訪問站點中的特定點而不要求他們的請求通過同一點是否更有效？但是，實際影響可能不是很糟糕？也許現代建築可以處理它？也許在它變得更值得考慮之前，你的規模必須是真正巨大的？我很好奇這個網站上的人對這個問題的看法。
總之，拉斯穆斯或解釋是錯誤的。
這顯示了計算機工作原理的明顯缺乏。使用的東西越多，它越接近CPU，因此更快，。請注意，單點輸入！=單點故障。但是，沒有關係，當人們說單點輸入時，我們正在討論這個應用程序，它是您邏輯的一個入口點。
更不用說它在架構上腦死亡沒有一箇中心入口點，或減少一般入口點的數量。只要你想在你的應用程序的每個入口點做一件事，猜猜有多少地方需要改變？處理了一個應用程序，每個頁面都是獨立的，它吸引了不得不改變，我向你保證，我們需要它。
重要的是，您使用一個Web框架，通過負載均衡和聲明性代碼等方法支持可伸縮性。
不，單入口點本身並不會造成瓶頸。谷歌的首頁得到了很多點擊，但他們有很多的服務器。
所以答案是：沒關係。
這是我一開始想的，但它似乎沒有影響。畢竟，你的入口點通常只做一些事情：設置一些環境常量，包括引導加載器，可選地捕獲拋出的任何異常並分配前端控制器。我認爲這是不是低效的原因是因爲這個文件不會改變，取決於控制器，行動甚至用戶。
但我覺得這很奇怪。我現在正在自己構建一個小型MVC框架，但它與我所使用的大多數框架略有相反。我把控制器邏輯放在被訪問的文件中。例如，index.php將包含IndexController及其操作。至少這種方法對我來說工作得很好。
我認爲你只有一個入口點的最大優點就是安全性。如果在一個地方進行檢查和驗證，所有進入的輸入都不太可能破壞系統。
由於大多數php mvc框架都使用某種url重寫，或者至少在index.php之後自己解析任何東西，所以單個入口點是需要。
除此之外，我想每個上下文提供了切入點，說網絡（/ SOAP）/控制檯/ ...
就像軟件開發中的任何東西一樣，這取決於。 Rasmus對前端控制器風格框架的反對意見是，您必須在每次請求中預先加載如此多的代碼，從而使性能受到影響。這是100％真實的。即使您使用某種智能資源加載模塊/對象/等，使用框架也是一種性能平衡。你拿的性能損失，但作爲回報，你回來
「商業邏輯」（不管它是什麼）和模板/佈局邏輯的鼓勵分離 -
即時和（更重要的）統一訪問您將用於數據庫查詢的對象，所謂的服務，您的數據模型等
要像一個拉斯穆斯傢伙，這是不值得的性能損失。他是一名C/C++程序員。對他來說，如果你想以高性能的方式分離業務邏輯，你可以給PHP寫一個C/C++擴展。
所以，如果你有一個環境和團隊在那裏你可以很容易地編寫C/C++ PHP的擴展，你的時間到市場對性能比是可以接受的，那麼是的，扔掉你的前端控制器框架。
如果這不是你的環境，考慮生產率增加了前端控制器架構能帶給您(likely) simple CRUD Application。
只是爲了補充，人們通常認爲的事情是，因爲有一個php頁面，它是一個服務於所有請求的單個頁面。有點像排隊。
需要注意的重要一點是，每個請求創建腳本的實例，因此，負載是一樣的，如果在同一時間，正在同時訪問兩個不同的網頁。所以，仍然是相同的負載。實際上。
但是，一些框架可能有一大堆你不需要進入腳本的東西。有點像滿足所有可能的場景，這可能會導致負載。
就我個人而言，我更喜歡多頁，就像我混合使用oop和程序一樣。我喜歡php老派的方式。
使用前端控制器文件體系結構肯定有缺點。正如Saem解釋的，訪問同一個文件通常對性能有利，但是Alan Storm和Rasmus Lerdorf解釋說，試圖讓代碼處理多種情況（例如前端控制器試圖處理對網站上每個「頁面」的請求）導致代碼的臃腫和複雜的集合。對每個頁面加載使用臃腫和複雜的代碼集合可能被認爲是不好的做法。
SAEM爭辯說，一個前端控制器可以節省您不必在多個位置編輯代碼，但我認爲，在某些情況下，這是更好地分離出的冗餘解決。
擁有Web服務器實際使用的目錄結構可以使Web服務器變得更簡單，對開發人員更爲明顯。網絡服務器通過將URL轉換成傳統上代表的位置來提供文件比將它們重寫爲新的URL更簡單。對於開發人員而言，非前端控制器文件體系結構可能更爲明顯，因爲他們不是從一個臃腫的控制器開始處理所有事情，而是從一個更加專用於他們需要開發的文件/控制器開始。
我認爲這是一個很大的誤解，從「一個文件」和「幾個文件」的角度來討論這個問題。
一個人傾向於認爲，因爲入口點是在一個文件中，那麼我們所要關注的是該文件中的代碼 - 這是錯誤的。
所有流行的框架都有大量的文件，包含條目操作代碼，解釋代碼和請求驗證碼。代碼不在一個地方，而是遍佈在require/include語句的叢林中，根據請求和如何調用不同的類。
在這兩種情況下，請求都由不同的文件處理。
爲什麼我應該有一個帶有某種_detect_uri（）函數的入口點，該函數需要調用strpos（），substr（），strncmp（）等其他函數來清理，驗證和拆分請求字符串，當我可以只使用幾個入口點消除所有的代碼？
查看URI.php中的CodeIgniters _detect_uri（）函數。不要選擇CodeIgniter，它只是一個例子。其他框架也是如此。
您可以通過單個入口點以及多個入口點實現MVC模式的目標。
對兄弟。有人可能會爭辯說，Web服務器是一個單一的入口點。 Rasmus提出的不是DRY，因爲所有腳本都必須單獨加載相同的資源。前端控制器負責照顧。 – rick 2009-03-02 22:42:57