本篇文章給大家?guī)淼膬?nèi)容是關(guān)于PHP框架中MVC架構(gòu)的分析(附示例),有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助。
在說 MVC 架構(gòu)之前,先說說PHP框架吧。很多很多學(xué)完P(guān)HP語言的人,面對的就是PHP各種各樣的框架。什么TP啊、Yii啊、CI啊,還有很流行的laravel啊等等。
他們的大部分都會說自己是基于 MVC 的架構(gòu),接著你得試著去理解 MVC 的邏輯,并嘗試著用這樣的邏輯去構(gòu)建一個網(wǎng)站,然后會說 MVC 真香~
面試
很多 PHP 的面試中,可能會問關(guān)于 MVC 的問題,比如 MVC 到底是什么意思,怎樣理解這種架構(gòu)。然而很多人的理解是 model 是模型,他對應(yīng)著數(shù)據(jù)庫中的表結(jié)構(gòu);view 對應(yīng)著頁面,用于展示;controller 主要用來寫各種邏輯,關(guān)聯(lián)數(shù)據(jù)和頁面的顯示。
以上回答基本上沒有問題,但一個網(wǎng)站的結(jié)構(gòu)真的有那么簡單么?顯然不是
設(shè)計
在說之前,首先讓我們了解一下設(shè)計模式的一種:中介者模式。一個形象的理解就是:港行插頭和國行插頭的轉(zhuǎn)接頭。
在 MVC 架構(gòu)中 controller 就是這個轉(zhuǎn)接頭。它只負(fù)責(zé)把 model 中的數(shù)據(jù)轉(zhuǎn)接給 view,對于訪問者來說,他們是看不到 model 中保存的真實(shí)數(shù)據(jù)的。從另外一個角度來說,這種中介者模式可以很好的將兩層數(shù)據(jù)進(jìn)行友好的通信。
爬坑
這種模式真的那么好么?隨著業(yè)務(wù)邏輯的越來越復(fù)雜,會發(fā)現(xiàn) controller 中的代碼越來越多,甚至自己都不愿去調(diào)整和優(yōu)化冗余代碼。
但從宏觀上來說,網(wǎng)站無非是請求多一些,表單多一些,頁面多一些啊,其他也沒什么了,為什么會這樣呢?
沒錯,就是因?yàn)檫@樣或那樣的東西比較多,導(dǎo)致 controller 中每個方法都很長,那么能想到的解決方法就是拆分。
如果用過 yii 框架,那么你會知道最簡單的辦法是加一個請求form層,代碼如下:
- class AuthController {
- public function login() {
- $FLogin = new loginForm();
- $FLogin->save();
- }
- }
- // 一般在獨(dú)立的文件夾中
- class loginForm {
- public function __construct() {
- $post = $_POST;
- }
- //Vevb.com
- public function save() {
- }
- }
以上的就是解決 controller 中 form 表單的問題,這個問題基本上能緩解很多代碼問題。
發(fā)散
從解決 form 層來看,其實(shí)有很多類似的問題都能解決。我們知道前端有個叫做 vue.js 的框架,它里面提到一個概念叫做 MVVM 模型。
其實(shí)在展現(xiàn)復(fù)雜頁面的時候,后端在對外輸出數(shù)據(jù)時,完全也可以采用這玩意進(jìn)行數(shù)據(jù)輸出。至于如何建立這樣的一個模型,那就具體得看業(yè)務(wù)邏輯了。
這里簡單拿用戶中心舉個例子,因?yàn)橥@里不僅僅需要一個表的數(shù)據(jù):
- class AuthController {
- public function userCenterAction() {
- return new userVM();
- }
- }
- class userVM {
- public $user;
- public $orders;
- public $other;
- public function __construct() {
- $this->user = $this->getUser();
- $this->orders = $this->getOrders();
- $this->handle();
- }
- private function getUser() {
- return NULL;
- }
- private function getOrders() {
- return NULL;
- }
- private function handle() {
- }
- }
以上代碼中,有個 VM 層,可以將相關(guān)獲取數(shù)據(jù)的代碼放在各自的方法中,然后在 handle 方法中自由組合。這樣在 controller 中的代碼也非常便于管理。
再想想,有沒有可以封裝的其他層呢?其實(shí)是有的,比如 request 層,還有經(jīng)常被框架封裝好的 validate 層,還有 laravel 中比較流行的 Middleware 層等等。只能說系統(tǒng)越復(fù)雜,層越多。
每個復(fù)雜系統(tǒng)的背后都蘊(yùn)含著高級開發(fā)工程師和架構(gòu)師的設(shè)計思路。以上說那么多,不知道讀者能否理解這些東西,就拿以上代碼來說,里面就蘊(yùn)含著另一種設(shè)計模式:建造者模式。
總結(jié):
代碼寫多了,也就知道其中蘊(yùn)含的道理了。當(dāng)一個新框架誕生后,關(guān)注點(diǎn)從學(xué)習(xí)這個框架,慢慢變成了這個框架是如何設(shè)計的,解決什么樣的問題。哪些地方用了比較好的技術(shù)和方法,從中能收獲到什么。一些地方的設(shè)計思路是什么樣的,有么有更好的設(shè)計,為何我能想到,對方想不到呢,是不是我遺漏了什么。
前幾年使用過各種 PHP 框架,小到 CI,大到 Symfony。不用那么多框架,也體會不到這些東西。學(xué)習(xí)編程其實(shí)和英語一樣,沒什么捷徑可以走。
多寫,多想,多練......
新聞熱點(diǎn)
疑難解答