PHP搭建自己的web框架的方法

本篇內容主要講解“PHP搭建自己的web框架的方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“PHP搭建自己的web框架的方法”吧!

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

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

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

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

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

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

       URL router：很關鍵的一個組件，決定著源碼文件的組織結構、代碼的清晰度。一個好的router，能方便地找到邏輯入口，體現框架的易用性。

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

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

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

以上是程序的基本框架結構，或者說是業務的流程結構，通常作為系統最重要的部分。但離實用還有距離，還有很多基礎功能要增加，比如session的處理，數據庫訪問，日志處理等功能。這些基本功能一般是可以獨立于框架的，可以在不同的框架上應用。功能類不要與框架耦合太緊，一般使用組合方式。我們將這些基礎功能按照用起來順手的方式封裝成核心類，使用單例或多例來調用，或對類進一步封裝成全局使用的方法，方便使用。

如上圖，中心把握好、梳理好了，體現的是業務能力，因為隨著業務發展，自然會形成業務分層的結構；而周邊結合得好，體現的是框架能力，如何用得/開發得舒適順手的問題。

在調用功能類或者業務類時，都會涉及到類的加載或導入問題。那是否使用自動加載功能呢？根據個人體驗和IDE支持程度，我覺得不直觀，對IDE不友好，如F3找不到定義的方法，這是我們開源系統學習的感受，還有對性能的影響。還是直接require/include方便，雖然多寫了些代碼，但確實對開發維護閱讀帶了極大的方便（除了修改名稱后導致引用變更不很方便，但可通過全局搜索來修改）。一些公共的類在入口里全局引用，業務類按需引用。性能損失？因為業務大部分時候都是垂直的，一般使用require/include即可，不需要require_once/include_once，即使多使用幾個once也沒什么關系，首先可保證正確性，且程序總體性能不是這個決定的。自動加載會增加很多判斷、指令還有棧操作，文件的查找、損失的性能更多吧。不過一個好的自動加載實現還是可以考慮引入的，業務類的文件可以考慮，框架性的文件不使用自動加載，并且要簡單、定位準確、高效、避免重復。

加載后怎么使用?方法、類對象方法還是類靜態方法調用？根據不同的場景決定。全局功能一般是方法調用，如thinkPHP獲取配置內容的C方法，直接調用。如果在分層中，接口層->業務層->數據訪問層，使用類靜態方法調用。一些全局功能操作，如數據庫操作類、一些第三方功能類、多態功能類，這些一般使用單例來使用，不需要多次產生新對象。

關于反射功能，注解，IOC，面向切面編程等在其它語言中很有用的功能和實踐，在PHP也基本能實現，雖然也看了很多實踐例子，但并沒有考慮運用到項目之中，能實現并不代表一定要用。LAMP能方便地開發一個網站，且一般是做網站應用，與做一個框架（如spring）是有區別的，因此對PHP的使用更多是關注網站的業務流程及其性能上，使業務流程清晰易于維護，使靈活性不至于復雜化業務、損害性能。高性能網站需要短平快，更何況很多網站是PHP做前端渲染，c/c++/java做后臺業務，所以PHP網站就應盡量簡單。因為我們是一個業務網站系統，業務流程是確定的，執行是從頭到尾的，體現在代碼上是業務代碼要清晰的，如果在執行過程中被反射了一把，注入了一把，會影響人對業務的理解，同時開發維護BUG定位的時候也可能忽視框架動了什么手腳。不像一些通用的框架或者第三方包，需要足夠的靈活供調用，靈活性就比較繞，還要犧牲一定的性能。使用這些功能，往往事先都要做一些初始化代碼，或者一些配置初始化，并且每個HTTP請求都要執行一次，即使再簡單的功能，沒有必要，不像java那樣只初始化一次。比如一些restfull框架會在入口處定義路由，還有大量的配置，這個雖然有一定的清晰靈活度，但這種情況下建議使用約定優于配置的思想。

以上的一些做法有些與眾不同或極端，但是也是經歷過原始-->框架(高級特性，技巧)-->回歸原始的過程，可以理解為個人的獨特感受或經驗。使用PHP的基本特性，從項目入手、業務流程理解、到開發維護，都使人輕松。性能方面沒有過多損耗，也能方便定位優化。總之原始簡單是對性能最好的提升；業務垂直隔離地編寫，一眼就看出做了什么是對開發效率的提升。

如果一開始沒有能力按項目要求開發自己的PHP框架，那么在第一次使用一個框架后，在其它項目中就應考慮自己按需實現網站，并形成自己的框架。

我覺得最簡單好上手的PHP網站框架，需要一個路由、一個控制器配合一個視圖模板引擎。其它功能模塊則按需添加。

到此，相信大家對“PHP搭建自己的web框架的方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！