優(yōu)點

1.容易上手，配置、部署方便

2.編譯緩存機制有利于性能提升

3.內置了對REST的支持

MVC和OO啥的就不說了...

缺點

1.麻煩的URL路由

正常模式：
URL -> URL路由 -> 將從URL解析得到的參數(shù)和請求傳遞給入口函數(shù)

TP的實現(xiàn)（以正則路由為例）：

正則 -> 入口文件 + 動態(tài)參數(shù)
如：'/^blog\/(\d+)$/' => 'Blog/read?id=:1'

簡潔的實現(xiàn)：

'/^blog\/(\d+)$/' => read // function read($id) {...}

此實現(xiàn)便于檢查路由規(guī)則與入口函數(shù)的匹配性并使用戶更加方便的使用解析后的URL參數(shù)，同時，TP的入口文件設計本就是多此一舉。

2.糟糕的模型設計

*1 需要手動建立模型與數(shù)據(jù)庫的關聯(lián)

缺點：需要進行一系列不必要的配置，與定義模型后自動生成數(shù)據(jù)庫表的行為相悖。

*2 對數(shù)據(jù)庫的抽象遠遠不夠

操作模型時有很強烈的操作數(shù)據(jù)庫感覺，同時由于 2*1 需要手動建立模型與數(shù)據(jù)庫的關聯(lián) 這一缺點，毫無必要的字段映射讓人惱火。

3.垃圾的模板引擎

*1 不支持模板繼承

重復寫代碼很累的親！

*2 XML格式的模板標簽

書寫不便，同時容易與HTML標簽混淆（最近幾年出現(xiàn)的模板引擎已經(jīng)很少有用XML標簽的了...）

*3 不適合前端書寫

模板 + 數(shù)據(jù) -> 渲染輸出

模板由前端書寫，數(shù)據(jù)由后臺提供，顯然TP的模板對此支持并不好。

*4 不支持模板的部分緩存

缺點：假設頁面P由A, B兩部分組成，A的更新頻率大于B，則頁面P的更新頻率與A相同。