一、MVC需要模板
MVC最早是在SmallTalk语言的开发过程中总结出的一种设计模式，MVC分别代表了"模型"、"视图"和"控制"，目的就是让不同的开发角色在大中型项目中各司其职。在网络应用程序的开发中，可以用下图来表示各概念之间的关系。
该图展示了一个简单的WEB应用程序，用户在浏览器上看到信息是数据库服务器上的内容，但在这之前经过了应用服务器加工。开发人员负责的就是建立数据结构、处理数据的逻辑以及表示数据的方法。"
96年CGI在中国开始流行的时候，早期的WEB程序员都是从HTML开始自学成材的，在PERL中print一行行的HTML并不是一件难事，但是随着网络的一步步提速，页面大小也从当初的二、三十K暴涨了十倍。写CGI程序就产生了一个迫切的要求：分开PERL和HTML源码。于是，社会进步体现在开发小组内部的分工上。由于美工和程序员对互相的工作并不是十分熟悉，在进行合作的过程中需要用一种约定的"语言"进行交流。
这种语言并不是我们的母语或者英语，术语叫做"模板"，逻辑和表示依靠它联系。它是结合了HTML和脚本语言特征的一种表达方式。通过这种方式，表示层可以按照用户所希望的格式来显示经过逻辑层处理过的数据。如果你有Windows平台下MFC的开发经验,那么一定会很熟悉Document/Document Template/View的封装，这就是一个很典型的MVC例子。对于Web应用来说，个人认为J2EE中的EJB/servlets/jsp(SUN企业级应用的首选)是最强大的，当然还有简洁优美的Structs。另一个很有名的实现就是COM/DCOM+ASP，这个组合在我国是最多人使用的。
通过几种MVC实现在WEB应用程序里的对比，可以得到一个关于模板的概念：一组插入了HTML的脚本或者说是插入了脚本HTML，通过这种插入的内容来表示变化的数据。下面给出一个模板文件的例子，这个模板经过处理后在浏览器里显示"Hello, world!"
$greetings
这里暂且省略处理方式，在后面做专门对比讨论。
二、为什么选SMARTY?
对PHP来说，有很多模板引擎可供选择，比如最早的PHPLIB template和后起之秀Fast template，经过数次升级，已经相当成熟稳定。如果你对目前手中的模板引擎很满意，那么......也请往下看，相信你作为一个自由软件爱好者或者追求效率和优雅的开发者，下面的SMARTY介绍多少会有点意思。
除了个人偏好的影响，我一直倾向于使用官方标准的实现，比如apache(Unix平台最流行的WEB服务器平台)的xml(标准化越来越近了)引擎Axis。好处就是可以获得尽可能好的兼容性(比如早期MFC对于Win3x的兼容性就比其它的应用程序框架好，当然现在各种版本都很完善了)。SMARTY发布之前我一直使用的是PEAR 中的Integrated Template eXtension。这个引擎和PHPLIB template、Fast template几乎是兼容的，从模板的语法到对模板的处理同出一辙：都是将模板读入内存然后调用parse()函数，用数据对预置的标记进行替换。
下面看看SMARTY是怎么做的。接到request后，先判断是否第一次请求该url，如果是，将该url所需的模板文件"编译"成php脚本，然后redirect；如果不是，就是说该url的模板已经被"编译"过了，检查不需要重编译后可以马上redirect，重编译条件可以自己设定为固定时限，默认的是模板文件被修改。
怎么样，看起来是不是有点眼熟？想起来了──这不就是jsp(SUN企业级应用的首选)的原理嘛！的确，这种"编译"用在PHP这样的解释性脚本引擎上显得匪夷所思，但是仔细想想，JAVA不也是由JVM解释执行的吗？这就叫"没有做不到，只有想不到"。
既然谈到了JAVA，就再对PHP的未来发表一点看法。PHP官方网站上宣布了要在2003年年底发布PHP5.0版。这个版本拥有很多崭新的特性：比如异常处理，命名空间，更加面向对象等等。可以说越来越向JAVA靠拢，SMARTY也是新特性之一，使得PHP更适用于大中型项目的开发。但是似乎离我当初选择它的原因──灵巧易用──越来越远了。但就一个软件的生存周期来看，PHP正处在成长期，开发者赋予它更多的功能，以期能胜任商业应用是利大于弊的。作为PHP的忠实用户，肯定不希望PHP总是被人指责"能力不足"吧？
