Ⅰ 詳解php實現MVC的幾種方法
相信所有習慣了使用MVC來組織自己的項目的人，讓他選擇一個新的項目構架時，一定不會放棄MVC。傳統的面相過程式的開發方式在處理中型以上的應用時，就開始顯得力不從心。即便我們能夠快速的完成需求，但是在需求發生變更後或者進行後期維護的時候，我們會深深地陷入我們早期搭建的陷阱中。什麼是MVC？關於MVC的定義和解釋，可以說多種多樣。我們可以在Wiki或者[2]中找到更為詳盡的解釋，這里我並不打算，也沒有能力進行深入的講解，從PHP開發的角度來講，MVC可以概括為：視圖(The View)：一說到視圖，我們很多人都會想到模板引擎(諸如Smarty等等)。其實就是各種各樣的輸出，比如說html模板和Javascript文件等。模塊(The Model)模塊代表了程序的邏輯，在企業應用中通常稱為業務邏輯層。一般來講，這一層完成的工作是把原始的數據處理成按照我們設計的數據結構存儲的有意義的數據序列，並將這些數據交給視圖去處理。通常情況下， 模塊中會利用一個數據抽象類來進行與數據操作有關的處理。 關於MVC的是否適合PHP的爭論也很多，人們不斷的討論MVC是否適合PHP[3]，現在也已經有了很多的MVC框架，諸如PHP MVC Frameworks中列出的[4]。那麼，為什麼人們這么熱衷於MVC，我們為什麼要使用MVC在我們的設計中呢。為什麼用MVC？MVC最早是用來解決桌面GUI的編程問題，最早的MVC框架應該是Sun在1999年提出的Model 2，後來演變成了Struts。MVC帶給人們深刻的印象，但是我們在使用的過程中，卻並沒有認真的想過為什麼使用MVC。在傳統的桌面應用中，一旦Model中有時間發生，我們可以主動的讓View界面進行刷新，從而展示後台發生的變化。而在Web應用中，我們似乎限於傳統的Http的Request/Response的方式，我們似乎沒有辦法讓用戶端進行更新。這一段討論，並不是認為MVC不能夠用來進行WEB應用的開發，而是覺得從某種程度上來說，他還不是最合適的。關於使用MVC的爭論還有很多[1]，但是相信所有習慣了使返嫌用MVC來組織自己的項目的人，讓他選擇一個新的項目構架時，一定不會放棄MVC。如何PHP實現MVC？下面是一個超級簡單的MVC結構實現，甚至連數據源都用了一個內置的固定數組，雖然簡單，但其實眾多的PHP Framework核心實現的思想應該和這個是差不多的，只不過一些framework提供了更多的方便開發者使用的工具，我也漏衫手想自己來實塌李現一個PHP的框架，目前正在著手策劃中，也希望自己能夠從框架的開發中學習到更多的PHP設計思想和方法。
Ⅱ 簡述MVC思想與PHP如何實現MVC
簡單的說就是將網站源碼分類、分層。
MVC三個字母的含義：
M：Model 模型，負責資料庫操作。
V：View 視圖，負責調用Model調取數據，再調用模板，展示出最終效果。
C：Controller 控制器，程序的入口，決定改調用哪個View，並告訴View該做什麼。
如此說來，程序的執行順序是C-V-M 或 C-M ，和MVC的名字正好相反。
Ⅲ php的tp框架和mvc有啥區別
首先說Model吧。
在TP中是一個表對應一個Model,而且普通Model中只是一些自動驗證啊，自動完成啊、還有數據欄位信息啊一些東西;而CI中的Model則完全不同，一個Model不必約束於一個表，也就是說名字為abc的Model中你也可以查詢名字為def的表中的數據，而且可以定義方法完成一些數據查詢，比如我可以在名為articles_model的Model中定義一個名字為get_articles的方法來獲取所有文章信息，當某個Controller載入了這個Model後，就可以在相應的Controller中用
1
$this->articles_model->get_articles();
來方便地獲取所有文章信息，而對於TP來說，這些操作只能在Action類中完成。2.0版的TP已經把View、Relation和Adv三個高級查詢model庫類定為不自動載入了，看了一下手冊，感覺除了View視圖查詢容易用一點，另外兩個都不怎麼好用，感覺用起來太復雜，還不如用原生的SQL查詢。CI的Model還有一個使我很喜歡的方法就是dbprefix方法，在使用原生的sql查詢時使用這個函數使得修改資料庫表名前綴後你的代碼不需要經過任何改動。在TP中我沒有發現類似的函數，當我用TP開發一個博客系統時，發現關聯查詢很麻煩，於是想用原生的SQL查詢，卻沒有找到自動增加資料庫表名前綴的方法，雖然可以自己修改TP的核心庫來實現，但是還是覺得這樣有點不太好。真的要感謝TP，如果不是TP，也許我就不會去關注CI了，當我那天看了幾頁CI的英文文檔後，立馬就對它產生的深厚的興趣，於是第二天一起床就開始看CI的手冊，雖然是從官網下的英文版的，不過它的手冊寫得很簡潔、很周到，邊看邊操作，看完手冊後我就幾乎能熟練使用這個框架了。於是用它開發了一個博客系統。
CI的Model類簡單易用，TP的Model類功能相對來說要強大一些，但是用起來個人感覺沒有那麼方便。
其次，對於View，從功能上講，TP的View要更加強大一些，選擇更多一些，在TP中你可以選擇就用PHP作模板引擎，可以就用TP自身的模板引擎，也可以選擇用smarty等其它第三方模板引擎。而在CI中就只能用CI內置的功能簡單的模板引擎或者用原生的PHP代碼作模板，個人覺得用PHP作模板更好一些，一來省去了學習另外的模板引擎語法的麻煩，二來執行效率更高一些。因些從View來講，選擇CI或者是TP都無所謂。
再次是Controller了，在CI中的應用的控制器是繼承自核心類Controller的，TP中的控制器則是繼承於核心類Action。不過還是有不同的，在TP中，你可以把一些公共的變數或者在多個控制器中都要執行的東西放在一個action里，假如這個action文件為CommonAction.class.php ，在它的_initialize方法中可以執行一些在多個控制器中都要執行的代碼或者初始化一些多個控制器都要使用的變數，這樣，應用的其它action只要繼承CommonAction 就可以實現了。因為框架在載入相應action時首先會自動載入那個CommonAction的。而在CI中就沒有這個方便的功能了，但是也可以自己寫一個library,在該library類的__construct方法里放一些代碼，然後在每個控制器中都載入這個library,這樣也可以實現像TP一樣的功能。不過相對來說麻煩了一些。TP還有一點比較靈活的就是，在這個控制器(action)裡面可以執行那個控制器中的函數（比如用A或者R函數來實現），在CI中則不行，你不能在這個控制器中執行那個控制器中的函數。還有就是TP可以定義一個名為EmptyAction的控制器，當所有控制器都找不到時，就調用這個Empty控制器。這一點如果與empty方法配合，可以使得URL大大縮減。雖然CI和TP都支持空操作，不過這二者的空操作名稱不相同，實現的優先順序也不相同。在TP中的空操作(_empty方法)優先順序是最低的，也就是說當當前控制器的所有操作都找不到時才調用這個空操作；在CI中則恰恰相反，只要存在空操作（_remap方法），該控制器的其它的操作都沒用了（不能訪問了）。
Ⅳ 什麼是MVC以及PHP怎樣實現MVC
其實你的問題一開始就問錯了，即然你問了，我就隨便說說好了。
MVC 是一種設計風格，並不是一種具體手法。每個人寫代碼都有自己習慣的一種設計風格。MVC 是應用程序開發常用的一種風格，實際上並不適合 PHP，因為 PHP 的工作環境註定了它很難做出像樣的控制器，也就是 Controll 。
MVC 本來的設計風格是：整個系統由一個程序啟動，再根據用戶操作調用各個處理模塊，根據數據結果來決定顯示成什麼樣給用戶看。就像我們平時用的各種程序的主界面。這樣程序員創建好主程序以後，只要把注意力集中在開發各個子功能上就可以了。。
可是 php 大多數情況下工作於 web 環境，有「頁」的概念，每次執行都是一個新的請求。這就註定了很難實現真正的 MVC，因為用戶看到頁面時，PHP 已經執行完了，不可能再切換去調另一個 模型M 和 視圖V 。
目前自稱 MVC 的各種框架。也只不過是用一個程序判斷請求，載入不同的功能塊。只能稱之為「單點入口」，在思路上是「請求相同的部份，而包含不同的部份」。這個入口程序實際上啥也沒做，所以算不上是 MVC。反而 JS 開發的富客戶端更接近一些。由一個 JS 主程序，跟據用戶請求決定調用哪些數據，再把界面改變成什麼樣。
設計風格是前人總結出來的東西，在當前語言，當然環境，當前思維方式下。比較容易繼續思考的一種設計方式。MVC 只不過是其中一種，而且並不是最適合 PHP 的一種。偏偏被炒作得好像標准似的。。
如果你一定要， 就去看一下 「PHP 單點入口實現」吧，已經是比較接近的東西了。如果一次性的控制器也能算控制器的話……