文章分享

一、MVC需要模板

MVC最早是在SmallTalk語言的開發(fā)過程中總結(jié)出的一種設(shè)計(jì)模式，MVC分別代表了"模型"、"視圖"和"控制"，目的就是讓不同的開發(fā)角色在大中型項(xiàng)目中各司其職。在網(wǎng)絡(luò)應(yīng)用程序的開發(fā)中，可以用下圖來表示各概念之間的關(guān)系。

該圖展示了一個簡單的WEB應(yīng)用程序，用戶在瀏覽器上看到信息是數(shù)據(jù)庫服務(wù)器上的內(nèi)容，但在這之前經(jīng)過了應(yīng)用服務(wù)器加工。開發(fā)人員負(fù)責(zé)的就是建立數(shù)據(jù)結(jié)構(gòu)、處理數(shù)據(jù)的邏輯以及表示數(shù)據(jù)的方法。

96年CGI在中國開始流行的時候，早期的WEB程序員都是從HTML開始自學(xué)成材的，在PERL中print一行行的HTML并不是一件難事，但是隨著網(wǎng)絡(luò)的一步步提速，頁面大小也從當(dāng)初的二、三十K暴漲了十倍。寫CGI程序就產(chǎn)生了一個迫切的要求：分開PERL和HTML源碼。于是，社會進(jìn)步體現(xiàn)在開發(fā)小組內(nèi)部的分工上。由于美工和程序員對互相的工作并不是十分熟悉，在進(jìn)行合作的過程中需要用一種約定的"語言"進(jìn)行交流。

這種語言并不是我們的母語或者英語，術(shù)語叫做"模板"，邏輯和表示依靠它聯(lián)系。它是結(jié)合了HTML和腳本語言特征的一種表達(dá)方式。通過這種方式，表示層可以按照用戶所希望的格式來顯示經(jīng)過邏輯層處理過的數(shù)據(jù)。如果你有Windows平臺下MFC的開發(fā)經(jīng)驗(yàn),那么一定會很熟悉Document/Document Template/View的封裝，這就是一個很典型的MVC例子。對于Web應(yīng)用來說，個人認(rèn)為J2EE中的EJB/servlets/JSP是最強(qiáng)大的，當(dāng)然還有簡潔優(yōu)美的Structs。另一個很有名的實(shí)現(xiàn)就是COM/DCOM+ASP，這個組合在我國是最多人使用的。

通過幾種MVC實(shí)現(xiàn)在WEB應(yīng)用程序里的對比，可以得到一個關(guān)于模板的概念：一組插入了HTML的腳本或者說是插入了腳本HTML，通過這種插入的內(nèi)容來表示變化的數(shù)據(jù)。下面給出一個模板文件的例子，這個模板經(jīng)過處理后在瀏覽器里顯示"Hello, world!"

這里暫且省略處理方式，在后面做專門對比討論。

二、為什么選SMARTY?

對PHP來說，有很多模板引擎可供選擇，比如最早的PHPLIB template和后起之秀Fast template，經(jīng)過數(shù)次升級，已經(jīng)相當(dāng)成熟穩(wěn)定。如果你對目前手中的模板引擎很滿意，那么......也請往下看，相信你作為一個自由軟件愛好者或者追求效率和優(yōu)雅的開發(fā)者，下面的SMARTY介紹多少會有點(diǎn)意思。

除了個人偏好的影響，我一直傾向于使用官方標(biāo)準(zhǔn)的實(shí)現(xiàn)，比如APACHE的XML引擎Axis。好處就是可以獲得盡可能好的兼容性(比如早期MFC對于Win3x的兼容性就比其它的應(yīng)用程序框架好，當(dāng)然現(xiàn)在各種版本都很完善了)。SMARTY發(fā)布之前我一直使用的是 PEAR 中的Integrated Template eXtension。這個引擎和PHPLIB template、Fast template幾乎是兼容的，從模板的語法到對模板的處理同出一轍：都是將模板讀入內(nèi)存然后調(diào)用parse()函數(shù)，用數(shù)據(jù)對預(yù)置的標(biāo)記進(jìn)行替換。

下面看看SMARTY是怎么做的。接到request后，先判斷是否第一次請求該url，如果是，將該url所需的模板文件"編譯"成php腳本，然后redirect；如果不是，就是說該url的模板已經(jīng)被"編譯"過了，檢查不需要重編譯后可以馬上redirect，重編譯條件可以自己設(shè)定為固定時限，默認(rèn)的是模板文件被修改。

怎么樣，看起來是不是有點(diǎn)眼熟？想起來了──這不就是JSP的原理嘛！的確，這種"編譯"用在PHP這樣的解釋性腳本引擎上顯得匪夷所思，但是仔細(xì)想想，JAVA不也是由JVM解釋執(zhí)行的嗎？這就叫"沒有做不到，只有想不到"。

既然談到了JAVA，就再對PHP的未來發(fā)表一點(diǎn)看法。PHP官方網(wǎng)站上宣布了要在2003年年底發(fā)布PHP5.0版。這個版本擁有很多嶄新的特性：比如異常處理，命名空間，更加面向?qū)ο蟮鹊取？梢哉f越來越向JAVA靠攏，SMARTY也是新特性之一，使得PHP更適用于大中型項(xiàng)目的開發(fā)。但是似乎離我當(dāng)初選擇它的原因──靈巧易用──越來越遠(yuǎn)了。但就一個軟件的生存周期來看，PHP正處在成長期，開發(fā)者賦予它更多的功能，以期能勝任商業(yè)應(yīng)用是利大于弊的。作為PHP的忠實(shí)用戶，肯定不希望PHP總是被人指責(zé)"能力不足"吧？

為什么選擇SMARTY，僅僅因?yàn)樗芟馢SP？當(dāng)然有更為充分的理由。首先，除了第一次編譯的成本比較高之外，只要不修改模板文件，編譯好的cache腳本就隨時可用，省去了大量的parse()時間；其次SMARTY像PHP一樣有豐富的函數(shù)庫，從統(tǒng)計(jì)字?jǐn)?shù)到自動縮進(jìn)、文字環(huán)繞以及正則表達(dá)式都可以直接使用；如果覺得不夠，比如需要數(shù)據(jù)結(jié)果集分頁顯示的功能，SMARTY還有很強(qiáng)的擴(kuò)展能力，可以通過插件的形式進(jìn)行擴(kuò)充。

事實(shí)勝于雄辯。我設(shè)計(jì)了一個測試程序，通過速度和開發(fā)難度這兩個因素對比了一下SMARTY和PHPLIB template，選PHPLIB template的原因是在patrick的文章 《在PHP世界中選擇最合適的模板》中有一個PHPLIB template對Fast template的競賽，結(jié)果PHPLIB template大獲全勝，這使得SMARTY有了一個很好的對手。在測試之前，先談一下在安裝過程中需要注意的問題。

三、可能遇到的問題

在SMARTY的 官方網(wǎng)站上，有詳盡的用戶手冊，可以選擇在線HTML和PDF格式的版本。這里就不再涉及手冊上已有的內(nèi)容，只是把初次使用可能遇到的問題做個解釋。

第一個問題就很要命：提示說找不到所需文件？并不是每一個人都按照SMARTY默認(rèn)目錄結(jié)構(gòu)來寫應(yīng)用的。這里需要手工指定，假設(shè)目錄結(jié)構(gòu)如下：

就需要在index.php里指定目錄結(jié)構(gòu)：

第一個問題解決了，緊接著就是第二個：我剛用Dreamweaver生成的漂亮模板怎么不能用？并不是模板文件有什么問題，而是因?yàn)镾MARTY默認(rèn)的標(biāo)記分隔符是{}，不巧的是Javascript肯定包含這個標(biāo)記。好在我們可以用任意字符當(dāng)作分隔符，再加上這兩句：

這下安裝就基本完成，沒問題了。

四、反襯和類比

先構(gòu)思一下對測試的設(shè)計(jì)。主要的評比因素當(dāng)然是速度了。為了進(jìn)行速度測試，采取了算術(shù)平均數(shù)的作法。在測試頁面中重復(fù)將頁面生成N遍，再對比總頁面生成時間。另一個重要因素是易用性(至于擴(kuò)展性不用比較已經(jīng)有結(jié)果了)，所以使用的模板不能太小。我用的是我個人主頁的的頁面，一個用Firework+Dreamweaver生成的HTML文件，大小約7K。其中的變量設(shè)置也采取最常用的區(qū)塊，在PHPLIB template里叫block,而SMARTY則稱section。別小看這稱呼的不同，易用性標(biāo)準(zhǔn)分兩塊：模板文件和腳本文件的語法是否簡明易用。

下面就深入到測試中來。先看看兩種模板文件的語法：藍(lán)條左邊是PHPLIB template的模板，右邊屬于SMARTY。個人偏好是不一樣的，所以這里不作評論。著重對比一下腳本里的處理語句，先看PHPLIB template的:

下面是SMARTY的：

SMARTY只用了tags和row兩個變量，而PHPLIB template則多了模板文件的handler，還有一個莫名其妙的out。說實(shí)在的這個out我當(dāng)初學(xué)的時候就不知道為什么要存在，現(xiàn)在看起來，還是別扭。為什么SMARTY少那么多處理語句呢？答案是工作由引擎完成了。如果你喜歡鉆研源程序，可以發(fā)現(xiàn)在Smarty_compiler.class.php里有一個名叫_compile_tag()的函數(shù)，由它負(fù)責(zé)把section這個標(biāo)簽轉(zhuǎn)換成php語句。這不是一個普通的標(biāo)簽，它帶有參數(shù)和數(shù)據(jù)，節(jié)省了腳本編程的工作量，而模板標(biāo)簽上的工作量相差又不大，可以判定在易用性上SMARTY高出一疇。

下面該輪到我們最關(guān)注的速度了，畢竟對于一個熟練的web開發(fā)者來說，掌握再困難的工具不過是時間問題，何況模板引擎這種學(xué)習(xí)曲線平緩的技術(shù)。而速度則是web應(yīng)用程序的生命，尤其是模板引擎使用在并發(fā)訪問量很大的站點(diǎn)上，這點(diǎn)就更重要了。測試開始前，我覺得PHPLIB template會在這一環(huán)節(jié)上勝出，因?yàn)樗?jīng)歷了很多次升級，已經(jīng)基本沒有什么bug,而且SMARTY的引擎?zhèn)€頭太大，不像它的對手只有兩個文件。

果然，測試結(jié)果如下圖，PHPLIB template有25%的速度優(yōu)勢：

但不會一直這樣，我又按了一次刷新，這次得到了不一樣的結(jié)果：

PHPLIB基本沒變化，但是SMARTY提高了25%的速度。繼續(xù)刷新，得到的都是類似于第二次的結(jié)果：SMARTY比PHPLIB template 快上近10%。我想這就是編譯型比解釋型快的原理了。SMARTY引擎本身就很大，加上還要把模板編譯成php文件，速度當(dāng)然比不上小巧的PHPLIB template。但這只是第一次的情況。第二次接到請求的時候，SMARTY發(fā)現(xiàn)該模板已經(jīng)被編譯過了，于是最耗時的一步被跳過了，而對手還要按部就班地進(jìn)行查找和替換工作。這是編譯原理里講到的很經(jīng)典的"用空間換時間"例子。

五、結(jié)論

結(jié)論就是如果你已經(jīng)愛上SMARTY了，那么還等什么呢？當(dāng)然并不是說它就全能，就如同我用MVC模式來寫我的個人網(wǎng)站，非但沒有減少工作量，反而總是要為不同層次間的耦合勞神。

SMARTY不適合什么呢？舉個手冊里的經(jīng)典例子：天氣預(yù)報網(wǎng)站。我還想到一個：股市大盤。在這種網(wǎng)站上用SMARTY會由于經(jīng)常的重編譯而效率偏低，還是PHPLIB template更為適合。

本文并不是為了對比兩種引擎，而是為了說明SMARTY的優(yōu)勢。使用它最有意義之處在于它是PHP新體系的一部份，作為一支獨(dú)立的力量，除了.NET和JAVA ONE這兩大體系之外，大中型web開發(fā)還有別的選擇。這對于GNU項(xiàng)目來說，其意義無異于劉鄧大軍千里躍進(jìn)大別山。

https://www.ibm.com/developerworks/cn/linux/l-smart/index.html