什么是MVC

MVC是一個(gè)可以讓你把“三個(gè)部分（即MVC的全稱，Model、 View、Controller）”諧調(diào)地組成一個(gè)復(fù)雜應(yīng)用程序的概念。一輛汽車(chē)就是一個(gè)在現(xiàn)實(shí)生活中非常好的MVC例子。我們看車(chē)都看兩個(gè)View（顯 示）部分：內(nèi)部和外部。而這兩個(gè)都離不開(kāi)一個(gè)Controller（控制者）：司機(jī)。剎車(chē)系統(tǒng)、方向盤(pán)和其他操控系統(tǒng)代表了Model（模型）：他們從司 機(jī)（Controller）那里取得控制方法然后應(yīng)用到內(nèi)部和外觀（View）。

網(wǎng)絡(luò)上的MVC

MVC框架所涵蓋的概念相當(dāng)簡(jiǎn)單并且極度靈活。基本的概念就是，你有一個(gè)單獨(dú)的控制器（如index.php）用來(lái)控制所有建立在參數(shù)請(qǐng)求基礎(chǔ)上的框架內(nèi)應(yīng)用程序。這個(gè)控制器通常包含了（最小程度上）一個(gè)定義模型的參數(shù)、一個(gè)事件和一個(gè)GET參數(shù)。這樣控制器就能確認(rèn)所有的請(qǐng)求然后運(yùn)行相應(yīng)的事件。打個(gè) 比方來(lái)說(shuō)，一個(gè)像這樣/index.php?module=foo&event=bar的請(qǐng)求很有可能就是用來(lái)載入一個(gè)名叫foo的類(lèi)，然后運(yùn)行 foo::bar()[就是其中的bar()函數(shù)]。這樣做的好處有：

一個(gè)對(duì)應(yīng)所有應(yīng)用程序的接口

同時(shí)維護(hù)一個(gè)應(yīng)用程序內(nèi)無(wú)數(shù)的代碼非常麻煩，因?yàn)槊恳欢未a都有自己的相對(duì)路徑、數(shù)據(jù)庫(kù)鏈接、驗(yàn)證等等。而這樣做就免除你在這方面的煩惱，允許你合并并重復(fù)使用代碼

為什么要?jiǎng)?chuàng)建自己的MVC框架

迄今為止，我沒(méi)有見(jiàn)到過(guò)太多用PHP寫(xiě)的MVC框架。事實(shí)上我僅僅知道一個(gè)－Solar，是完全用PHP5寫(xiě)的。另外一個(gè)是Cake，一個(gè)試圖成為 PHP的RoR（Ruby on Rails－一個(gè)Ruby語(yǔ)言開(kāi)源網(wǎng)絡(luò)框架）。我自己對(duì)這兩個(gè)框架都有一些不滿意的地方：它們都沒(méi)有利用到PEAR，Smarty等所包含的現(xiàn)有代碼；現(xiàn) 在的Cake還比較紊亂；最后，Solar是一個(gè)絕大部分由一個(gè)人寫(xiě)的作品（我無(wú)意說(shuō)其作者Paul不是一個(gè)好人或者好程序員）。這些問(wèn)題可能并不會(huì)讓你 否認(rèn)它們，而且很有可能你根本不關(guān)心這些問(wèn)題。但是正因?yàn)槿绱耍艺?qǐng)各位盡可能地審視它們。

老方式

如果回到2001看自己寫(xiě)的代碼，作者有可能找到一個(gè)叫template.txt的文件，它看起來(lái)像這樣：

＜?php require_once('config.php'); // Other requires, DB info, etc. $APP_DB = 'mydb';$APP_REQUIRE_LOGIN = false; // Set to true if script requires login$APP_TEMPLATE_FILE = 'foo.php'; // Smarty template$APP_TITLE = "My Application"; if ($APP_REQUIRE_LOGIN == true) {if (!isset($_SESSION['userID'])) {header("Location: /path/to/login.php");exit();}} $db = DB::connect('mysql://'.$DB_USER.':'.$DB_PASS.'@localhost/'.$APP_DB);if (!PEAR::isError($db)) {$db-＞setFetchMode(DB_FETCHMODE_ASSOC);} else {die($db-＞getMessage());} // Put your logic here // Output the templateinclude_once(APP_TEMPLATE_PATH.'/header.php');include_once(APP_TEMPLATE_PATH.'/'.$APP_TEMPLATE_FILE);include_once(APP_TEMPLATE_PATH.'/footer.php'); ?＞

只是看這些代碼都會(huì)讓我有退縮的欲望。這段代碼的概念就是確保每一個(gè)應(yīng)用程序都能適用于這個(gè)處理方法，比如我可以簡(jiǎn)單地將 template.txt拷進(jìn)myapp.php，改變一些變量，瞧，它就能運(yùn)行起來(lái)了。盡管如此，這個(gè)組織嚴(yán)密的處理方法存在一些嚴(yán)重的缺點(diǎn)：

如果我的老板想讓作者用myapp.php在一些情況下輸出PDF、一些情況下輸出HTML、一些情況下（直接提交的XML請(qǐng)求）SOAP，我該怎么辦？

如果這個(gè)應(yīng)用程序需要IMAP或LDAP驗(yàn)證，我該怎么辦？

我該如何處理各種不同的代碼（包括編輯、升級(jí)和刪除）？

我該如何處理多級(jí)驗(yàn)證（管理員 vs. 非管理員）？

我該如何啟用輸出緩存？

新方式

將所有東西都扔進(jìn)這個(gè)MVC框架，你會(huì)發(fā)現(xiàn)生活是如此簡(jiǎn)單。請(qǐng)對(duì)比以下代碼：

＜?php class myapp extends FR_Auth_User{public function __construct(){parent::__construct();} public function __default(){// Do something here} public function delete(){ } public function __destruct(){parent::__destruct();}} ?＞

注意這段代碼顯然不是用來(lái)鏈接到一個(gè)數(shù)據(jù)庫(kù)、判斷一個(gè)用戶是否已經(jīng)登陸、或者輸出任何其他信息。控制器掌握了所有的一切。

如果我想驗(yàn)證LDAP，我可以建立FR_Auth_LDAP。控制器可以識(shí)別某些輸出方法（比如$_GET['output']）并可以隨時(shí)轉(zhuǎn)換成 PDF或者SOAP。事件處理delete，只負(fù)責(zé)刪除，其他的它都不管。因?yàn)檫@個(gè)模塊擁有一個(gè)FR_User類(lèi)的實(shí)例，它可以簡(jiǎn)單地判斷一個(gè)用戶是否已 經(jīng)登陸等等。

Smarty，作為模板引擎控制緩存是理所當(dāng)然的，但是控制器同樣可以控制一部分緩存。

從前面講的老方式到MVC方式對(duì)于很多人來(lái)講可能是一個(gè)全新、陌生的概念，但是一旦你轉(zhuǎn)換到了這樣一個(gè)概念，那么要轉(zhuǎn)回去將是件相當(dāng)困難的事情。