smarty：最好让它做最难的部分还是更好地为它提供 php-precompiled html？答案

【问题标题】：smarty: better let it doing the hard part or better serving it php-precompiled html?smarty：最好让它做最难的部分还是更好地为它提供 php-precompiled html？
【发布时间】：2013-09-06 08:52:31
【问题描述】：

我在徘徊。如果我必须构建一个菜单，或者说，一组基于产品数据数组的规格表。换句话说，如果我必须渲染一个数组，什么是更好（从性能的角度来看）：

一个。在 php 中构建所有 html（比如在控制器中）并将我保存 html 的变量传递给 smarty

b.在 php 中什么都不做，将数组传递给 smarty 并在模板中构建相关的 html？

【问题讨论】：

从性能的角度来看，smarty 第一次编译模板可能并不重要，因为它会将模板转换为 php 代码。从实际的角度来看……您应该使用 smarty 将逻辑与表示分开。如果你想用php创建html代码，就不要使用smarty。
好的，谢谢。我正在使用prestashop，所以我必须使用smarty，如果它对处理器来说更重，我正在徘徊，直接的php（显然应该是精心制作的）html转换或smarty渲染。但是，你是对的，这里的重点应该是将逻辑与表示分开。尽管如此，在这种情况下至少对我来说有点模棱两可，因为如果我传递原始数组并使用 smarty 完成所有操作，我最终会得到 smarty 中的逻辑（对于循环，首先设置最后一个偶数奇数项等等)。

标签： php arrays performance smarty template-engine

【解决方案1】：

Smarty 模板在第一次被处理时就被编译成 PHP 代码，所以除非你在做一些特别奇特的处理，这些处理很难用 Smarty 语法表达，否则性能很可能会非常相似。

这个问题听起来也很像“过早的优化”：您预先假设某事可能是性能问题，并在获得任何可衡量的结果之前花费精力“优化”它。当您实际需要测量一些性能并且可以找到代码的哪些部分可以为您带来最大的改进时，这些能量会更好地保存下来。

无论是您的选择还是您正在使用的应用程序，像 Smarty 这样的模板语言的想法是它包含您所有的显示逻辑，因此将显示逻辑移动到“控制器”中（大概这也是MVC 思维方式中的“视图”）打败了分离点。

如果你真的讨厌 Smarty，你可能会编写自己的“视图”层，它将所有输出预处理为 HTML，并将单个变量传递给 Smarty 模板，但我不确定你是这样的重来。

【讨论】：