在PHP中應用MVC的介紹(一)

(Walter.Fan編譯自Jason E. Sweat寫的An Introduction to MVC Using PHP)

MVC在B/S大行其道的今天,恐怕是設計模式中最為著名的一種啦.
對於website來說,它是一種不錯的架構.
所謂MVC即Model-View-Controller模型-視圖-控制器,是一種物件導向的設計模式.MVC用類將商務邏輯(資料存放區在哪裡,哪些使用者被准許處理這些資料,如何處理這些資料)放在模型中,表示邏輯(來自模型的資料怎樣被表示出來)放在視圖中,而將應用程式的整個流程式控制制放在控制器中.

PS.設計模式是程式員的內功心法,有關的設計模式的九陰真經就是"四人幫"的"Design Patterns". 在http://www.phppattenrs.com上有關於設計模式在PHP中的應用的介紹.

為什麼要用MVC?
因為MVC是一種對於website所存在問題的一種極好的解決方案.在website中,每個頁面的點擊都是使用者和系統的互動(輸入).假設你有某些需求去維護儲存的資料與其顯示方式之間的狀態,MVC模式就是在你的應用程式非常適合的一種架構

MVC模式在建立方案時專註於三類問題
1.處理持久儲存的資料(資料庫或檔案)
2.處理應用程式的邏輯控制流程程,向使用者顯示什麼,在應用程式中允許使用者對於資料執行何種動作
3.在應用程式中向使用者顯示資訊

JSP/J2EE在MVC的應用方面比較http://blog.csdn.net/images/blog_csdn_net/fanyamin/102481/r_phpmvc1.gif成熟,有非常多的經驗可供我們借鑒,參見以下網址
http://java.sun.com/blueprints/patterns/MVC.html
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/webtier/web-tier5.html
http://developer.java.sun.com/developer/onlineTraining/JSPIntro/contents.html#JSPIntro4

在JSP規範說明中所提到的"Model 1"和"Model 2"
Model 1: 在系統中用類封裝了模型,但是視圖散佈於不同的布面,也沒有頁面流程式控制制器
Model 2: 推薦方式,由控制器對象負責應用程式的流程式控制制

JSP/J2EE世界中有不少非常精妙的MVC的實現方案,其中鼎鼎大名就有Struts(http://jakarta.apache.org/struts/)

模型Model
Models 是MVC應用程式中實現商務邏輯的組件,而
商務邏輯是與資訊儲存相關的任何PHP邏輯代碼
模型一詞來自於真實世界中,它類似於規則與資料
模型是在系統中唯一與持久性資料存貯打交道的組件.
(比如在web請求中儲存或檢索資料).
模型可在web開發中實現任何技術: 資料庫調用,檔案處理,會話管理,web services或其他儲存資料的手段.

一個設計優良的模型能在web伺服器中被其他應用程式使用.
當你開始見識到用這些類封裝商務邏輯的威力,你會清楚地認識到製作一個良好的模型是一個非常有用的習慣,即使你不用完全的MVC架構

對於和資料庫表互動的模型,一個單獨的表最好有一個相關聯的一個類
這將協助我們獲得MVC好處的第一點:在某種持久性資料存貯中處理資料
只要堅持MVC的架構,如果資料庫表改動了,那我們只需在系統中檢查這個對應的模型
在web應用程式中典型的例子就是使用者,訪問者, 購物車,目錄項,訂單,標題或文章
在資料庫驅動的web應用程式中,模型趨向於關聯於單個資料表,或者一些緊密耦合在一起的表(或視圖). 作為一種合理的命名規則,模型類的名字可與資料庫表的名字類似.
我也傾向於為website的功能寫模型類,例如對於多頁的表單可以有一個關聯的模型嚮導類.

視圖View
視圖是MVC應用程式中向使用者表示輸出的組件.
最通常的PHP應用程式輸出是HTML,但視圖不僅限於此.
MVC應用程式亦可輸出XML, WML, 純文字,映像, 郵件或其他內容
在視圖中PHP有廣泛的應用,發送資料到瀏覽器,實現模板解決方案等
總的來說,視圖建立模型的執行個體,使用模型的方法去擷取資料並展現給使用者.
在應用程式中,視圖包含所有必需的將位元據轉換為所需的資料表示格式的PHP代碼.比如,利用GD庫畫圖的代碼在MVC中就屬於視圖

控制器Controller
控制器是MVC應用程式的核心組件,它必須知道使用者的HTTP請求(或者是命令列輸入參數),從而決定顯示什麼視圖,或者產生應用程式的其他什麼相應動作.
總之,控制器是任何MVC項目的核心組件(主要因為模型和視圖必鬚根據它們的性質而適用於你的應用程式).  不同的項目有不同的策略去決定視圖和模型如何互動.
這些對象之間的互動就是系統的耦合.如果用一個設定檔(常用基於XML的檔案)來定義它們之間的關係,這就是所謂的"鬆散耦合". 相反的做法就是在系統中寫入程式碼應用程式流程程.

描述了Web開發的各種技術在MVC三個組件中的應用

實際情況中,這些技術也許有交叉. 例如如果你的應用程式中包含一個User模型,
而且你有一個"記住我"的功能,你也許想用User模型發送一個cookie值到用戶端瀏覽器. 我們應將這個任務通過HTTP分配給控制器. 還有我們也許要考慮在哪裡顯示一個模型的執行個體表示視圖,通過URL參數去顯示哪一個視圖.結果,視圖可能通過$_GET來訪問擷取這些資訊.(通過HTTP串連從控制器又到視圖). 我們不應該在視圖和模型之間看到這些技術的交叉使用.
在模型中決不要夾雜HTML,在視圖中決不要包含任何資料庫訪問功能.
任何以上做法都違反了我們將內容與格式分離的原則,打破了MVC模式,並限制了應用程式的靈活性.

網上已有許多基於PHP的開源項目
Ambivalence
http://amb.sourceforge.net/
This project is a port of the java project called

Maverick (http://mav.sourceforge.net/), which originated
as an attempt to simplify Struts.

Eocene
http://eocene.net/
An MVC framework with a goal to port to ASP.NET.

php.MVC
http://www.phpmvc.net/
A port of the java-based Jakarta Struts framework

phpPatterns() MVC2
http://www.phppatterns.com/index.php/article/articleview/19/1/1/
The second article on this site about the MVC pattern.

Phrame
http://phrame.itsd.ttu.edu/
Another port of the Struts framework.

結合項目實踐
一般來說,基於PHP的MVC應用程式都有兩個總的流程路徑.見
第一個流程路徑是使用者發送請求以獲得一個特定的視圖.
第二個流程路徑是使用者輸入內容並更新模型的資料

第一個流程路徑
1. 控制器負責解釋使用者以HTTP的GET方式發送的請求.
並針對這個請求,決定切換到哪一個相應的視圖.
2.應用程式流程程轉到視圖,通常視圖需要來自於模型的資料來顯示響應結果.
3.視圖請求擷取來自於模型的資料.
模型是唯一可以訪問持久性資料存貯容器(資料庫或檔案)的組件.
4.模型向持久性資料存貯容器中查詢資料
5.模型從持久性資料存貯容器中擷取資料
6.模型向視圖返回資料
如果視圖需要當前或其他模型中的資料,根據需要重複第三步到第六步
7.視圖格式化並發送這些輸出給使用者作為響應.

第二個流程路徑
MVC Web應用程式另一個的通用流程是在應用程式中由使用者更新資料
描述這個流程路徑
1. 控制器接收到請求(類似於從使用者的瀏覽器以HTTP POST方式提交請求)
2. 控制器決定採取什麼動作,並以適當的參數調用模型對象的方法響應這個請求
 模型將根據代碼中的商務邏輯判斷這個請求是否有效
3. 如果請求有效,模型將調用相應的方法改變資料
4. 返回更新結果
5. 模型將控制權交還給控制器
6. 控制器確定使用者下一步的指向
7. 重新導向到相應的地址,在發布header()命令之後,本次請求就此結束了