來源：互聯網
上載者：User
關鍵字
PHP
HTML
Thinkphp
smarty
我是真沒發現它們的用處在哪裡？分離了前端和PHP的依賴？HTML檔案確實沒有寫PHP代碼了，但是卻有smarty或者Thinkphp的模板引擎代碼在裡面，PHP程式員要學，前端人員也要學，這不是反而增加了開發時間和開發難度？吃力不討好？而且用了模板引擎勢必要在PHP層面對HTML代碼進行字串替換解析，都知道字串替換是很耗效能的，費時又浪費效能的。僅僅為了分離前端跟PHP，我覺得這相當不划算。是否我對其作用（僅僅為了分離前端和PHP，方便各司其職）理解有偏差？請賜教！
回複內容：
項目小，一個人折騰的時候，怎麼快怎麼來，構建MVC，解耦頁面資料代價比較大，所以你會說沒用；
項目大了，人多了，代碼複用、規劃、編碼規範、人員溝通的成本急劇上升。
把每個人的工作串連起來，需要規則；
減少條條框框的束縛，大家各司其責專註自己的工作，避免互相干擾，才能提高效率。
回到你的問題。我分解成下面四個點：
1. 為什麼要出現模版引擎？
2. PHP本身不就可以起到直接在HTML結構裡面嵌邏輯指令碼了嗎？
3.為什麼又演變出獨立的文法
4.效能開銷怎麼考慮
1. 為什麼要出現模版引擎？
Z：請設想有兩個人合作一個項目，一個負責頁面部分，一個後台資料。（其實就是前端與後台）
那麼他們應該專註在自己負責的部分。
以頁面的同學為例，他應該只關心資料如何呈現，如何互動，如何將使用者資料傳給後台。那麼目前業內的實踐經驗是，前端與後台約定好頁面參數及介面協議，即可各自獨立開發。
2. PHP本身不就可以起到直接在HTML結構裡面嵌邏輯指令碼了嗎？
Z：前面說到，合作中應該各自專註自身工作，避免互相干擾。頁面的同學直接在頁面模版中有可能操作PHP指令碼中的全域變數、屬性、方法；背景同學在給頁面傳值後有可能意外修改到參數。。。這些都是因為他們的環境沒能隔離開的緣故。
那麼比較好的方案就是給頁面模版一個獨立的參數範圍，將頁面參數單獨傳遞進去。
3.為什麼又演變出獨立的文法
為了減輕頁面開發的學習負擔，也讓頁面更加直觀。請比較：
{{ innerHTML }}
使用MVC，在View層我也覺得用原生的PHP代碼比模板引擎更高效，這個跟項目的大小無關，PHP本身就是最優秀的範本語言。這些模板系統是以前為了代碼和樣式分離遺留下來的。現在普遍都是 MVC 架構，所以基本沒用了。
PS：小系統也應該用 MVC，機器比人工便宜多了，開發效率最重要。一般有這種疑問的多是代碼量偏小的。
分離是為了便於維護，犧牲部分開發效率用以便於日後維護也是很正常的事情吧。
如果是你，你願意維護一個PHP與HTML全部寫在一起的亂糟糟的系統，還是願意維護一個MVC三層分明的項目？
學習不是什麼大問題，大多數架構的上手速度都不慢。而且對於一般架構來說，他的首要解決的問題之一就是快速開發，開發效率不是問題。
運行效率有損耗是正常的，因為mvc這種模式，本身就是一種犧牲效率提高穩定性的方案。用ThinkPHP開發已三年！簡單說一下感受
（1）第一年：因為懶得學ThinkPHP內建模板引擎文法，就直接使用自己熟悉的Smarty；
（2）第二年：因為平時收集的不少ThinkPHP源碼，使用的是內建的ThinkPHP模板文法，沒辦法，就把內建的ThinkPHP引擎看了一遍，其實就是一二天事，基本上與Smarty沒有太大的區別，做幾個執行個體就掌握了；
（3）第三年：有一次在做一個項目時，需要在模板中使用原生的PHP字串函數做一個簡單替換，結果突然發現，居然不會寫了，要去查手冊！
太可怕了，這在二年前簡直不敢想象，以前閉眼都不會敲錯。
所以，各類模板引擎，在方便程式員的同時，也使大家對原生的PHP語言變得陌生了。
所以現在，拿到項目開工前，我會直接在Application下的公用設定檔中
'TMPL_ENGINE_TYPE' => 'php', // Think模板引擎使用原生PHP 'TMPL_TEMPLATE_SUFFIX' => '.php', // 預設範本檔案尾碼
代碼和樣式分離，當然，現在一種趨勢是直接js了，php都不要不懂，只知道我以前一個月開發的項目，現在兩周或者一周搞定。架構主要是為了我們這些民工服務，還是老老實實的寫代碼把，有本事自己也寫個架構出來刷刷
