PHP單入口是否是必須的

之前做的一些項目，一般自己整理結構的時候都這麼來：

/application
____/pc
________/controllers
________/views
____/mobile
________/controllers
________/views
/system
____/library
____/models
____/services
____system.php
/public
____/pc
________/assets
________index.php
____/mobile
________/assets
________index.php
/upload
/data

(不好意思，這個神編輯器的 UL/OL 真的用不來)

application：應用目錄，system：系統目錄，public：網站入口，upload：上傳目錄，data：緩衝session等。

主網域名稱綁定到 /public/pc 下，移動網域名稱綁定到 /public/mobile 下，各自的 index.php 定義各自 application 路徑，來給路由指明相應的 /Controllers 和 /views，另外都require 系統入口 /system/system.php 來實現常量定義、初始化和啟動應用。

因為是一個資料庫，所以 /models 放到了 /system 裡面公用，model 只是單純的表映射和 set/get/CURD 方法，為了最大程度的複用（比如 pc 站和移動站都需要某個模組的發布功能），業務操作直接移到 /services 裡面，action 只做最簡單的參數過濾、調用 service 執行業務、redirect。

問題來了：

最近打算做一個遊記類的網站，可以肯定的是只有 pc 端和移動端，暫不考慮 APP 應用，本來是考慮按照上面的單入口來的，但是網站功能真的很有限，幾個入口完全可以勝任，而且多入口省去了路由操作直接進商務邏輯可以壓榨一部分效能，單入口的參數雖然可以用 htaccess 改一下但肯定沒有多入口簡潔明了。多入口每個頭裡面 require 系統核心 system.php 一樣可以實現系統初始化、參數過濾、類庫函數庫載入的一些功能。

因為網站完全自己一個人做，團隊協作根本不存在，那這樣的：多入口+系統入口包含+services+DAO 是不是一樣可以做到 pc 站和移動站的複用（感覺按照最上面的形式，不一樣要寫兩遍 Controllers 麼...），另外最重要的一點，有沒有單入口是不是影響負載平衡包括資料庫主從等的實現呢（因為從來沒有過這方面的情境）？

其實我主要糾結的就是兩點：1、複用（直接寫死的話混寫一路到頭當然效率要高一些，但是移動端再重新寫一遍確實有點傻）；2、效能效能效能，和將來可能的抗壓能力。

回複內容：

之前做的一些項目，一般自己整理結構的時候都這麼來：

/application
____/pc
________/controllers
________/views
____/mobile
________/controllers
________/views
/system
____/library
____/models
____/services
____system.php
/public
____/pc
________/assets
________index.php
____/mobile
________/assets
________index.php
/upload
/data

(不好意思，這個神編輯器的 UL/OL 真的用不來)

application：應用目錄，system：系統目錄，public：網站入口，upload：上傳目錄，data：緩衝session等。

主網域名稱綁定到 /public/pc 下，移動網域名稱綁定到 /public/mobile 下，各自的 index.php 定義各自 application 路徑，來給路由指明相應的 /Controllers 和 /views，另外都require 系統入口 /system/system.php 來實現常量定義、初始化和啟動應用。

因為是一個資料庫，所以 /models 放到了 /system 裡面公用，model 只是單純的表映射和 set/get/CURD 方法，為了最大程度的複用（比如 pc 站和移動站都需要某個模組的發布功能），業務操作直接移到 /services 裡面，action 只做最簡單的參數過濾、調用 service 執行業務、redirect。

問題來了：

最近打算做一個遊記類的網站，可以肯定的是只有 pc 端和移動端，暫不考慮 APP 應用，本來是考慮按照上面的單入口來的，但是網站功能真的很有限，幾個入口完全可以勝任，而且多入口省去了路由操作直接進商務邏輯可以壓榨一部分效能，單入口的參數雖然可以用 htaccess 改一下但肯定沒有多入口簡潔明了。多入口每個頭裡面 require 系統核心 system.php 一樣可以實現系統初始化、參數過濾、類庫函數庫載入的一些功能。

因為網站完全自己一個人做，團隊協作根本不存在，那這樣的：多入口+系統入口包含+services+DAO 是不是一樣可以做到 pc 站和移動站的複用（感覺按照最上面的形式，不一樣要寫兩遍 Controllers 麼...），另外最重要的一點，有沒有單入口是不是影響負載平衡包括資料庫主從等的實現呢（因為從來沒有過這方面的情境）？

其實我主要糾結的就是兩點：1、複用（直接寫死的話混寫一路到頭當然效率要高一些，但是移動端再重新寫一遍確實有點傻）；2、效能效能效能，和將來可能的抗壓能力。

首先回答你的標題問題

PHP單入口是否是必須的

答案肯定不是，之所以單入口比較多的原因在於大多數流行的架構都是單入口的模式，至於優劣你已經有仔細考量過了，並且這個優劣也是智者見智，仁者見仁，就不做展開了。

1、複用（直接寫死的話混寫一路到頭當然效率要高一些，但是移動端再重新寫一遍確實有點傻）；

這個你也說了，程式執行效率 - 程式員維護效率，這是一個不可調和的矛盾，在這個矛盾下一定是

• 執行效率高 維護效率低
• ...(各種折中)
• 執行效率低 維護效率高

無論是哪種語言還是設計決策，其實都是在找折中點，你要確定你的折中點在哪裡，有時候犧牲一些效能，但是帶來維護效率的提高，那麼其實也不是不可以接受

拿你的這個多入口來說，無非就是在你的多個業務相同的入口內include相同的邏輯（極端情況把相同的邏輯變成一個後，又是你之前的模式），你可以將單入口“請求”抽象，設計成“業務請求”，在這個方向上進行你的邏輯微調，這就是你的多入口模式

2、效能效能效能，和將來可能的抗壓能力。

80%的效能問題都不在php程式本身，而在於php和php所串連的資源（例如mysql，file儲存），與其考慮php的問題，不如好好想想怎麼最佳化php對資源的訪問效率，如果最佳化php對資源的訪問效率到極致以後，或許你會採用phalcon或者直接把php替換成另外一個編譯語言

單入口方便管理

康盛的uchome 和 discuz!都不是單入口的!

