目前主流的php框架設計模式均為mvc模式，比如yii或codeigniter，均是由控制器接收頁面請求，並溝通模型與檢視的互動。如果我們把**整體看作乙個矩陣，把**接收使用者請求並處理看作是**的豎向，而把**的每乙個模組（比如文章模組，投票模組，論壇模組等）看作是**的橫向。
mvc模式，側重於豎向即請求、處理、呈現之間的協調，而忽略了模組之間的協調。
當使用者發起請求的時候，由哪個模組來處理使用者的請求已經確定了，這就使模組之間呈現非常強的獨立性，這該怎麼理解呢，舉個例子來說。 假設現在，你有兩個模組，乙個是新聞模組，乙個是模組，新聞模組展示一些新聞文章，模組用來展示。 如果用mvc,我們這樣實現：定義兩個控制器news,pic,兩個模型news_model,pic_model,兩個檢視 news_view,pic_view,當有使用者請求news控制器時，先呼叫news_model取得需要的資料，再用這些資料渲染 news_view，最後呈現給使用者。
有一天，你的領導忽然有了新想法，hey,夥計，新聞模組只顯示新聞太單調，讓新聞模組，能顯示模組裡最熱門的。這下不好辦了，new_model裡沒有相關的模型，news_view裡也沒有顯示列表的檢視。你有解決辦法？把顯示列表相關的模型和檢視分別複製乙份到news的模型和檢視？不，這麼做不好，如果我現在全站都要顯示熱門列表你怎麼辦？還複製嗎？不可以的。後期維護會累死人。
在codeigniter框架裡，有更好一點兒的解決辦法，就是把顯示列表這個功能做 成乙個library，每需要的地方，呼叫library就可以，因為library有與控制器相同的溝通模型檢視的功能。但這會帶來乙個新的問題：資料 共享，如果頁面分割成不同的library來實現，不同的library的資料很難共享，library之間是完全獨立的。
現在來看，這一切的一切都是因為mvc模式注重豎向的溝通，而忽略了橫向的溝通，完全割裂了模組之間的關係。
模組溝通
textpattern(簡稱txp)是乙個小型的blog系統，它最大的特點是注重模組之間的溝通，完全模糊了不同模組間的界限，對與使用者的乙個請求，txp完全沒必要知道使用者請求的是什麼模組，新聞還是，只需要知道請求的頁面要呈現些什麼功能點。每乙個小功能點都是完全獨立的。
這是一種檢視驅動的模式，接收到使用者請求後，首先取到要請求的檢視，視**件再呼叫不同的功能點，這樣就弱化了模組之間獨立性。通俗點兒說：使用者想看什麼，你就給什麼，不要管它是不是同乙個模組，是不是有關係。wordpress也是基於檢視驅動的模式的。
hmvc
層疊式的mvc,這是mvc模式的公升級版本。首先把系統按功能點分，每個功能點的實現再採用mvc模式。hmvc同時兼顧了橫向和豎向的溝通。
我所認為理想的模式：基於檢視驅動的hmvc，基於檢視驅動，就是以使用者為基礎，呈現使用者想看到，以需求為驅動才是正確的。hmvc保證了**的重用，易於維護。
檢視驅動，可以借鑑wordpress的實現，因為wordpress的模板開發、替換很容易；橫向溝通的實現可以借鑑txp;豎向溝通就是典型的mvc了。
設計自己的MVC框架
事實是最近讀 j2ee設計模式 講述表達層模式的那幾章，書中有乙個前端控制器 command模式的workflow例子，就琢磨著可以很簡單地擴充套件成乙個mvc框架。花了乙個下午改寫了下，對書中所述的理解更為深入。我想這也許對於學習和理解設計模式，以及初次接觸struts等mvc框架的人可能有點幫助...
設計自己的MVC框架
publicinte ceaction 比如，我們要實現乙個登陸系統 demo的例子 loginaction驗證使用者名稱和密碼，如果正確，返回success頁面，如果登陸失敗，返回fail頁面 publicclassloginactionimplementsactionelse returnact...
PHP的MVC框架 深入解析
原文 php的mvc框架 深入解析 本篇先介紹一下php的mvc實現原理，我們框架的mvc部分也是基於此原理實現的，但是今天的 並不是框架內的 僅僅為說明原理 一 檔案結構 建立3個資料夾 controller資料夾存放控制器檔案 view資料夾存放視 件 model資料夾存放資料檔案 建立1個in...