本篇文章給大家一分鐘學(xué)會如何用PHP搭建自己的web框架？（分享）有一定的參考價值，有需要的朋友可以參考一下，希望對大家有所幫助。

這里講的WEB是指運行在apache下的PHP WEB程序。

首先要理解PHP在apache下的運行機制和請求的生命周期。

PHP是腳本語言，它的執(zhí)行過程就是從文件入口，一直到文件的最后的結(jié)尾，其中可以包含或引用其它文件，是面向過程的。在過程當(dāng)中，可以使用對象來實現(xiàn)各種需要的邏輯處理。你可以把一個或者多個對象拿來完成所需要的功能，你也可以告訴一個對象你要完成什么功能，這是面向?qū)ο蟮拈_發(fā)方法，也是普遍的開發(fā)方法。所以，在面向過程的運行機制中，使用面向?qū)ο蟮拈_發(fā)方式。

每一個HTTP請求的生命周期也是從入口開始，直到程序結(jié)束，其中的變量將不復(fù)存在，不同的HTTP請求的變量都是獨立互不影響的。我們可使用global聲明、$GLOBALS全局數(shù)組變量、static靜態(tài)變量在同一HTTP請求中共享數(shù)據(jù)；使用session來實現(xiàn)會話級別的共享；使用緩存來實現(xiàn)站點全局數(shù)據(jù)共享。global聲明一般在方法中，在面向過程的開發(fā)中使用，平時不會用到。$GLOBALS和static經(jīng)常會用到，但不能直接操作，而是在對象里或?qū)ｉT的方法來管理，比如常用的單例模式使用$GLOBALS和static保存。

PHP程序中，我們都會考慮盡量使框架簡潔、高效、清晰、易用，這對開發(fā)和維護都很有好處。

基本的程序模式使用MVC模式，分層分模塊、同時需要一個好用的URL router配合MVC。

URL router：很關(guān)鍵的一個組件，決定著源碼文件的組織結(jié)構(gòu)、代碼的清晰度。一個好的router，能方便地找到邏輯入口，體現(xiàn)框架的易用性。

Model: 一直用數(shù)組。用數(shù)組主要擔(dān)心數(shù)組內(nèi)容不清楚，在項目中，屬性參考數(shù)據(jù)庫字段，因此數(shù)組內(nèi)容還是相對明確的，Model的操作使用數(shù)據(jù)訪問層DAO封裝。數(shù)據(jù)庫訪問中，直接轉(zhuǎn)化為數(shù)組形式，也比較高效。對于其它系統(tǒng)的交互數(shù)據(jù)對象，一般有接口文檔定義。對于ORM中的Active Record技術(shù)，能不用還是不用的好。

View: 開始使用smarty，但在性能報告中，smarty執(zhí)行的方法耗時占比太多太多，后來使用tmd_tpl，就一個文件，簡單易用高效，易修改。在視圖模板中，結(jié)合PHP語法，并輔于模板變量。MVC的思想是分離，并不代表不能在View中使用PHP語法。如果是API接口，可以直接把數(shù)據(jù)轉(zhuǎn)化為具體格式結(jié)果并返回。

Controller: 或者action，代表著一個行為、一個方法、一個接口。只有一層的controller往往是不夠用的，一般要分成接口層、業(yè)務(wù)層、數(shù)據(jù)訪問層，可能還需要通信層。接口負責(zé)參數(shù)校驗、接入權(quán)限控制，調(diào)用具體的業(yè)務(wù)，最后返回數(shù)據(jù)或顯示頁面等。所有的業(yè)務(wù)最好都以接口層開始，在這之前應(yīng)只做框架方面的事情，當(dāng)我們需要閱讀某個業(yè)務(wù)實現(xiàn)時，只要順著接口層入口開始讀即可。業(yè)務(wù)層是執(zhí)行實際的業(yè)務(wù)功能，業(yè)務(wù)層從數(shù)據(jù)訪問層獲得數(shù)據(jù)并進行業(yè)務(wù)上加工處理。數(shù)據(jù)訪問層從數(shù)據(jù)庫或調(diào)用接口獲取數(shù)據(jù)，可進行簡單的數(shù)據(jù)轉(zhuǎn)換處理。如果PHP只是作為數(shù)據(jù)展示前端，后端由C/C++/GO等執(zhí)行業(yè)務(wù)，那只需要封裝業(yè)務(wù)層，在業(yè)務(wù)層里把數(shù)據(jù)請求到后端，然后返回給接口層。

以上是程序的基本框架結(jié)構(gòu)，或者說是業(yè)務(wù)的流程結(jié)構(gòu)，通常作為系統(tǒng)最重要的部分。但離實用還有距離，還有很多基礎(chǔ)功能要增加，比如session的處理，數(shù)據(jù)庫訪問，日志處理等功能。這些基本功能一般是可以獨立于框架的，可以在不同的框架上應(yīng)用。功能類不要與框架耦合太緊，一般使用組合方式。我們將這些基礎(chǔ)功能按照用起來順手的方式封裝成核心類，使用單例或多例來調(diào)用，或?qū)︻愡M一步封裝成全局使用的方法，方便使用。

如上圖，中心把握好、梳理好了，體現(xiàn)的是業(yè)務(wù)能力，因為隨著業(yè)務(wù)發(fā)展，自然會形成業(yè)務(wù)分層的結(jié)構(gòu)；而周邊結(jié)合得好，體現(xiàn)的是框架能力，如何用得/開發(fā)得舒適順手的問題。

在調(diào)用功能類或者業(yè)務(wù)類時，都會涉及到類的加載或?qū)雴栴}。那是否使用自動加載功能呢？根據(jù)個人體驗和IDE支持程度，我覺得不直觀，對IDE不友好，如F3找不到定義的方法，這是我們開源系統(tǒng)學(xué)習(xí)的感受，還有對性能的影響。還是直接require/include方便，雖然多寫了些代碼，但確實對開發(fā)維護閱讀帶了極大的方便（除了修改名稱后導(dǎo)致引用變更不很方便，但可通過全局搜索來修改）。一些公共的類在入口里全局引用，業(yè)務(wù)類按需引用。性能損失？因為業(yè)務(wù)大部分時候都是垂直的，一般使用require/include即可，不需要require_once/include_once，即使多使用幾個once也沒什么關(guān)系，首先可保證正確性，且程序總體性能不是這個決定的。自動加載會增加很多判斷、指令還有棧操作，文件的查找、損失的性能