用PHP實現MVC開發模式的邏輯層和表示層有多種模板引擎可供選擇，但是官方引擎SMARTY誕生後，選擇就有了變化。它的理念和實現都是相當"前衛"的。
MVC最早是在SmallTalk語言的開發過程中總結出的一種設計模式，MVC分別代表了"模型"、"視圖"和"控制"，目的就是讓不同的開發角色在大中型項目中各司其職。在網絡應用程序的開發中，可以用下圖來表示各概念之間的關系。
96年CGI在中國開始流行的時候，早期的WEB程序員都是從HTML開始自學成材的，在PERL中print一行行的HTML並不是一件難事，但是隨著網絡的一步步提速，頁面大小也從當初的二、三十K暴漲了十倍。寫CGI程序就產生了一個迫切的要求：分開PERL和HTML源碼。於是，社會進步體現在開發小組內部的分工上。由於美工和程序員對互相的工作並不是十分熟悉，在進行合作的過程中需要用一種約定的"語言"進行交流。
這種語言並不是我們的母語或者英語，術語叫做"模板"，邏輯和表示依靠它聯系。它是結合了HTML和腳本語言特征的一種表達方式。通過這種方式，表示層可以按照用戶所希望的格式來顯示經過邏輯層處理過的數據。如果你有Windows平台下MFC的開發經驗,那麼一定會很熟悉Document/Document Template/View的封裝，這就是一個很典型的MVC例子。對於Web應用來說，個人認為J2EE中的EJB/servlets/JSP是最強大的，當然還有簡潔優美的Structs。另一個很有名的實現就是COM/DCOM+ASP，這個組合在我國是最多人使用的。
該如何使我的PHP腳本從設計中獨立出來？這無疑地是在PHP郵件列表上所提問的最多的問題之一。雖然PHP被標榜為“HTML嵌入式語言”， 在寫過許多PHP和HTML混合式的工程之後，我產生了一個分離表單和內容的想法。而且，在許多公司裡規劃設計者的角色和程序設計者是分開的。於是，這樣的一個模板解決方案產生了……
例如在一個公司，一個應用程序的開發流程如下：在提交計劃文檔之後，界面設計者[美工]制作了網站的外觀模型，然後把它交給後台程序員。程序員使用PHP實現商業邏輯，同時使用外觀模型做成基本架構。然後工程被返回到HTML頁面設計者繼續完善。就這樣工程可能在後台程序員和頁面設計者之間來來回回好幾次。由於後台程序員不喜歡干預任何有關HTML標簽，同時也不需要美工們和PHP代碼混在一起；美工設計者只需要配置文件，動態區塊和其他的界面部分，不必要去接觸那些錯綜復雜的PHP代碼。因此，這時候有一個很好的模板支持就顯得很重要了。
縱觀現今存在的許多PHP模板解決方案（比如PHPLIB），大多數都只是提供了用模板取代變量和將動態區塊的功能有限的格式化的基本方法。但是我們的需求比這個要高的多。我們完全不想要PHP程序員去設計HTML頁面，可是這又是不可避免的。例如：如果美工想要在動態區塊之間交替不同的背景顏色，他就可能得和程序員預先說好。同樣，美工們也應該有自己對於頁面設計的配置文件，這同樣可以通過變量把他們拉到模板裡邊去。
Smarty是一個使用PHP寫出來的模板PHP模板引擎，是目前業界最著名的PHP模板引擎之一。它分離了邏輯代碼和外在的內容，提供了一種易於管理和使用的方法，用來將原本與HTML代碼混雜在一起PHP代碼邏輯分離。簡單的講，目的就是要使用PHP程序員同美工分離，使用的程序員改變程序的邏輯內容不會影響到美工的頁面設計，美工重新修改頁面不會影響到程序的程序邏輯，這在多人合作的項目中顯的尤為重要。
對PHP來說，有很多模板引擎可供選擇，比如最早的PHPLIB template和後起之秀Fast template，經過數次升級，已經相當成熟穩定。如果你對目前手中的模板引擎很滿意，那麼......也請往下看，相信你作為一個自由軟件愛好者或者追求效率和優雅的開發者，下面的SMARTY介紹多少會有點意思。
除了個人偏好的影響，我一直傾向於使用官方標准的實現，比如APACHE的XML引擎Axis。好處就是可以獲得盡可能好的兼容性(比如早期MFC對於Win3x的兼容性就比其它的應用程序框架好，當然現在各種版本都很完善了)。SMARTY發布之前我一直使用的是 PEAR 中的Integrated Template eXtension。這個引擎和PHPLIB template、Fast template幾乎是兼容的，從模板的語法到對模板的處理同出一轍：都是將模板讀入內存然後調用parse()函數，用數據對預置的標記進行替換。
下面看看SMARTY是怎麼做的。接到request後，先判斷是否第一次請求該url，如果是，將該url所需的模板文件"編譯"成php腳本，然後redirect；如果不是，就是說該url的模板已經被"編譯"過了，檢查不需要重編譯後可以馬上redirect，重編譯條件可以自己設定為固定時限，默認的是模板文件被修改。
怎麼樣，看起來是不是有點眼熟？想起來了──這不就是JSP的原理嘛！的確，這種"編譯"用在PHP這樣的解釋性腳本引擎上顯得匪夷所思，但是仔細想想，JAVA不也是由JVM解釋執行的嗎？這就叫"沒有做不到，只有想不到"。
既然談到了JAVA，就再對PHP的未來發表一點看法。PHP官方網站上宣布了要在2003年年底發布PHP5.0版。這個版本擁有很多嶄新的特性：比如異常處理，命名空間，更加面向對象等等。可以說越來越向JAVA靠攏，SMARTY也是新特性之一，使得PHP更適用於大中型項目的開發。但是似乎離我當初選擇它的原因──靈巧易用──越來越遠了。但就一個軟件的生存周期來看，PHP正處在成長期，開發者賦予它更多的功能，以期能勝任商業應用是利大於弊的。作為PHP的忠實用戶，肯定不希望PHP總是被人指責"能力不足"吧？
為什麼選擇SMARTY，僅僅因為它很像JSP？當然有更為充分的理由。首先，除了第一次編譯的成本比較高之外，只要不修改模板文件，編譯好的cache腳本就隨時可用，省去了大量的parse()時間；其次SMARTY像PHP一樣有豐富的函數庫，從統計字數到自動縮進、文字環繞以及正則表達式都可以直接使用；如果覺得不夠，比如需要數據結果集分頁顯示的功能，SMARTY還有很強的擴展能力，可以通過插件的形式進行擴充。
需要實時更新的內容。例如像股票顯示，它需要經常對數據進行更新，這類型的程序使用smarty會使模板處理速度變慢。
小項目。小項目因為項目簡單而美工與程序員兼於一人的項目，使用smarty會喪失php開發迅速的優點。
