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邮件列表上所提问的最多的问题之一。虽然php被标榜为“html嵌入式语言”， 在写过许多php和html混合式的工程之后，我产生了一个分离表单和内容的想法。而且，在许多公司里规划设计者的角色和程序设计者是分开的。于是，这样的一个模板解决方案产生了……
例如在一个公司，一个应用程序的开发流程如下：在提交计划文档之后，界面设计者[美工]制作了网站的外观模型，然后把它交给后台程序员。程序员使用php实现商业逻辑，同时使用外观模型做成基本架构。然后工程被返回到html页面设计者继续完善。就这样工程可能在后台程序员和页面设计者之间来来回回好几次。由于后台程序员不喜欢干预任何有关html标签，同时也不需要美工们和php代码混在一起；美工设计者只需要配置文件，动态区块和其他的界面部分，不必要去接触那些错综复杂的php代码。因此，这时候有一个很好的模板支持就显得很重要了。
纵观现今存在的许多php模板解决方案（比如phplib），大多数都只是提供了用模板取代变量和将动态区块的功能有限的格式化的基本方法。但是我们的需求比这个要高的多。我们完全不想要php程序员去设计html页面，可是这又是不可避免的。例如：如果美工想要在动态区块之间交替不同的背景颜色，他就可能得和程序员预先说好。同样，美工们也应该有自己对于页面设计的配置文件，这同样可以通过变量把他们拉到模板里边去。
什么是smarty smarty是一个使用php写出来的模板php模板引擎，是目前业界最著名的php模板引擎之一。它分离了逻辑代码和外在的内容，提供了一种易于管理和使用的方法，用来将原本与html代码混杂在一起php代码逻辑分离。简单的讲，目的就是要使用php程序员同美工分离，使用的程序员改变程序的逻辑内容不会影响到美工的页面设计，美工重新修改页面不会影响到程序的程序逻辑，这在多人合作的项目中显的尤为重要。
为什么选择smarty 对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编写的程序可以获得最大速度的提高，这一点是相对于其它的模板引擎技术而言的。 编译型：采用smarty编写的程序在运行时要编译成一个非模板技术的php文件，这个文件采用了php与html混合的方式，在下一次访问模板时将web请求直接转换到这个文件中，而不再进行模板重新编译（在源程序没有改动的情况下）。 缓存技术：smarty选用的一种缓存技术，它可以将用户最终看到的html文件缓存成一个静态的html页，当设定smarty的cache属性为true时，在smarty设定的cachetime期内将用户的web请求直接转换到这个静态的html文件中来，这相当于调用一个静态的html文件。 插件技术：smarty可以自定义插件。插件实际就是一些自定义的函数。 模板中可以使用if/elseif/else/endif。在模板文件使用判断语句可以非常方便的对模板进行格式重排。 不适合使用smarty的地方 需要实时更新的内容。例如像股票显示，它需要经常对数据进行更新，这类型的程序使用smarty会使模板处理速度变慢。
小项目。小项目因为项目简单而美工与程序员兼于一人的项目，使用smarty会丧失php开发迅速的优点。
http://www.bkjia.com/phpjc/752420.htmlwww.bkjia.comtruehttp://www.bkjia.com/phpjc/752420.htmltecharticle用php实现mvc开发模式的逻辑层和表示层有多种模板引擎可供选择，但是官方引擎smarty诞生后，选择就有了变化。它的理念和实现都是相当...