PHP 單一入口的特有作用

在說單一入口之前，先說說多入口。discuz!, phpcms 2008, dedecms 都是採用多入口的結構。

多入口，即通過訪問不同的 php 檔案執行對應的功能。如：

/index.php - **首頁

/show.php?id=1 - 內容頁

/list.php?page=2 - 列表頁

/login.php - 使用者登入頁

……多入口都是通過包含標頭檔案統一執行環境，即初始化系統。如：

/include/common.inc.php - 標頭檔案，php 檔案 include 它後便完成了初始化工作，例如可以使用系統的基礎函式。

/index.php

<?php

include './include/common.inc.php' // 包含標頭檔案，基本是每個入口 php 檔案的首行**。

……?>

拿 phpcms 2008 的標頭檔案來舉例， phpcms 2008 在標頭檔案中完成了基礎函式的載入，常量的定義，系統配置的載入，post,get 資料的過濾，資料庫類的例項化，保持使用者登入等等等等一系列操作。

反正就是個 php 檔案嘛，想做什麼直接往裡加就是了。

所以，所謂的安全檢查，統一檢查，許可權控制等，用標頭檔案同樣可以實現，所謂「單一入口」只不過是換了一種形式，並無實質性的變化。

以前我就是這樣認為的。

現在，假設用 cms 為客戶建乙個站（ cms 是多入口的）：建欄目，配**，卡拉卡拉一段忙碌後，**可以上線了，放在這個位址下：

localhost/gz/

沒錯，這次建的是 gz 這個地區的地區站，客戶認為**做得不錯，希望做多乙個 bj 地區的地區站。 bj 站的欄目結構，內容，功能模組等都與 gz 站有所不同。

好，現在問題來了，上面提到的三個多入口的系統，都設計成一套程式乙個環境，即一套程式只對應乙個資料庫。對於上面的需求（ bj 站），除非修改整套程式的結構（這是不切實際的），否則就只能複製多乙份源**，指向另乙個資料庫。

於是，我便複製多乙份源**，指向 bj 資料庫（ gz 站則指向 gz 資料庫），建欄目，配**，卡拉卡拉一優忙碌後，**又可以上線了，放在這個位址下：

localhost/bj/

所以，現在有兩套一樣的程式在執行。

然後，客戶想改一改 gz 站的功能，於是我修改了 gz 的**。然後，客戶想改一改 bj 站的功能，於是我修改了 bj 的**。然後，客戶想在 bj 站上做與 gz 同樣的修改，於是我得把 gz 的修改複製到 bj 中，然後……

於是，我不得不維護兩份實際上是「一樣」的**。

假如**運營得不錯，客戶又建了若干個地區站，我維護的便是若干份「一樣」的**——這根本就是惡夢。

現在到單一入口登場了。

單一入口，就是訪問同乙個檔案加不同引數執行不同的功能。如：

/index.php - 單一入口，預設顯示首頁

/index.php?action=show&id=1 - 用 action 引數指明顯示內容頁

/index.php?action=list&page=2 - 顯示列表頁

/index.php?action=login - 使用者登入頁

……index.php 這個入口做的便是標頭檔案做的初始化操作（外加一些排程），包括載入**的配置。

現在我們來假設建站用的 cms 是單一入口的設計，在完成 gz 站後，面對同樣的需求（ bj 站），我只需要在 /bj/ 目錄入多建乙個入口檔案，載入指向 bj 資料庫的配置，再配配資料卡拉卡拉什麼的，就完事了！

於是，我只需要維護乙份源**。

這便是單一入口特有的作用——構造環境。

使用哪個資料庫就是環境的一種，類似的還有：用記憶體快取還是檔案快取，用 mysql 還是 mssql 等。

除非在設計階段特別留意，否則，標頭檔案的結構都會被寫成「一套程式乙個環境」的結構。而採用單一入口結構，無論是否留意，都可以輕易實現「一套程式多個環境」。這才是使用單一入口的真正理由。