Question

请记住这是针对经典asp

哪个更好，所有HTML包含在Response.Write语句中或通过＆lt;％=％＆gt;将变量插入HTML中。
例如

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

我主要是从性能的角度询问，当要插入多个变量时，服务器的影响最小？

如果没有技术差异，那么一个人的争论是什么？

Answer 1

首先，您应该关注的最重要的因素是易于维护。你可以购买一个服务器农场，你需要浪费金钱和时间，因为必须破译一个凌乱的网站来维护它。

无论如何，没关系。在一天结束时，所有ASP都只是执行一个脚本！ ASP解析器获取页面，并将<%= expression %>转换为直接脚本调用，并且每个连续的HTML块都成为对Response.Write的一个巨大调用。生成的脚本将被缓存并重复使用，除非磁盘上的页面发生更改，这会导致重新计算缓存的脚本。

现在，过多使用<%= %>会导致现代版的“意大利面条代码”：可怕的“标签汤”。你将无法做出逻辑的正面或反面。另一方面，过多使用Response.Write意味着在呈现之前你永远无法看到页面。在适当的时候使用<%= %>以充分利用这两个世界。

我的第一条规则是注意“变量文本”与“静态文本”的比例。

如果您只有几个地方需要替换可变文本，<%= %>语法非常紧凑且易读。但是，随着<%= %>开始积累，它们会掩盖越来越多的HTML，同时HTML会掩盖越来越多的逻辑。作为一般规则，一旦开始进行循环，就需要停止并切换到Response.Write`。

没有太多其他硬性规则。您需要决定哪个页面（或页面部分）哪个更重要，或者更容易理解，或者更容易破解：您的逻辑或HTML？它通常是一个或另一个（我已经看过几百个案例）

如果你的逻辑更重要，你应该更加重视Response.Write;它将使逻辑脱颖而出。如果HTML更为重要，请使用<%= %>，这样可以使页面结构更加清晰。

有时我必须编写两个版本并将它们并排比较以确定哪个版本更具可读性;这是最后的手段，但是当代码在你脑海中浮现时你就会这么做，三个月后你必须做出改变时会很高兴。

Answer 2

从个人偏好的角度来看，我更喜欢＆lt;％=％＆gt;方法，因为我觉得它提供了一个更好的分离变量内容与静态内容。

Answer 3

除了其他人已解决的代码可读性/可维护性问题之外，当你有多个变量要插入时，你的问题是关于性能的 - 所以我假设你将多次重复类似你的代码片段。在这种情况下，您应该使用单个Response.Write获得最佳性能，而不连接所有换行符：

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

浏览器不需要换行符或制表符或任何其他漂亮的格式来解析HTML。如果你想要表现，你可以删除所有这些。您还可以缩小HTML输出，这样可以加快页面加载速度。

在单个变量的情况下，它并没有真正发挥很大作用。但对于多个变量，您希望最大限度地减少HTML和ASP之间的上下文切换 - 每次从一个跳转到另一个跳转都会受到影响。

为了在构建更长的语句时提供可读性，可以使用源代码中的VBScript行继续字符和选项卡（但不是输出）来表示结构而不会影响性能：

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

它不像HTML版本那么清晰，但如果你将大量变量放入输出中（即HTML和ASP之间的大量上下文切换），你会看到更好的性能。

性能提升是否值得，或者你是否会更好地扩展硬件是一个单独的问题 - 当然，它并不总是一个选择。

更新：请参阅Len Cardinal在此MSDN文章中的提示14和15，了解有关使用Response.Buffer提高性能并避免上下文切换的信息：http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15。

Answer 4

这里的许多答案表明这两种方法产生相同的输出，并且选择是编码风格和性能之一。它似乎认为静态内容超出＆lt; %%＆gt;成为一个Response.Write。

然而，将代码放在＆lt; %%＆gt;之外会更准确。与BinaryWrite一起发送。

Response.Write接受一个Unicode字符串，并在将其放入缓冲区之前将其编码为当前的Response.CodePage。 ASP文件中的静态内容不会发生此类编码。外面的字符＆lt; %%＆gt;将字节逐字节转储到缓冲区中。

因此，Response.CodePage与用于保存ASP文件的CodePage不同，两种方法的结果可能不同。

例如，假设我将此内容保存在标准的1252代码页中： -

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>

第一段是乱码，因为£不会使用UTF-8编码发送，第二段很好，因为提供的Unicode字符串编码为UTF-8。

因此，从性能的角度来看，使用静态内容是首选，因为它不需要编码，但如果保存的代码页与输出代码页不同，则需要小心。出于这个原因，我更喜欢保存为UTF-8，包括＆lt;％@ codepage = 65001并设置Response.Charset =“UTF-8”。

Answer 5

我更喜欢＆lt;％=％＆gt;大多数情况下的方法有几个原因。

HTML会暴露给IDE 它可以处理给你工具提示，标签关闭等
维持缩进输出HTML更容易非常有助于重新布局。
没有附加vbCrLf的新行一切都是为了审查输出源。

Answer 6

响应格式将呈现HTML，如下所示：

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

因此，生成代码的方法不仅不可读，而且结果也会被不正确地标记。坚持另一种选择。

Answer 7

我更喜欢<%= %>，因为它使Javascript开发更容易。您可以编写引用控件的代码，例如

var myControl = document.getElementById('<%= myControl.ClientID %>');

然后，我可以在我的javascript代码中以任何方式使用该控件，而不必担心硬编码ID。

Response.Write可以在某些情况下破坏一些ASP.NET AJAX代码，所以我尽量避免它，除非使用它来渲染自定义控件中的特定内容。

Answer 8

我在做ASP / PHP时尝试使用MVC范例。它使维护，重新架构和扩展的事情变得最容易。在这方面，我倾向于有一个代表模型的页面。它主要是VB / PHP并设置vars供以后在视图中使用。它还会在循环时生成大量HTML，以便以后包含在视图中。然后我有一个代表视图的页面。这主要是HTML，其中＆lt;％=％＆gt;标签。该模型在视图中是#include -d，然后离开。控制器逻辑通常在第三页或服务器端以JavaScript完成。

Answer 9

我的经典ASP生锈了，但是：

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

这是按原样运行的。但是，这个：

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

结果：

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

其中\ r \ n是vbCrLf

从技术上讲，第二个更快。但是，差异将在几毫秒内测量，所以我不担心。我更关心的是，最重要的一个是非常难以维护的（尤其是HTML-UI开发人员），其中第二个很难维护。

对@Euro Micelli的道具 - 维护是关键（这也是为什么像Ruby，Python这样的语言，以及过去（仍然......）C＃和Java在C，C ++和汇编人类的基础上踢的原因维护代码，这比削减页面加载几毫秒更重要。

当然，C / C ++等有它们的位置......但这不是它。：）

Answer 10

<%= %>其余内容扩展到Response.Write()，所以最后也是如此。

Answer 11

没有性能改进切换到Response.Write，使用快捷方式表示法可以更快地读取和维护。

Answer 12

您应该根据代码重用和代码可维护性（又称可读性）来构建这些问题。无论如何都没有任何性能提升。

Answer 13

＆lt;％= Bazify（）％＆gt; 在从短表达式内联某些HTML 生成HTML时非常有用。

当您需要使用大量代码进行 HTML内联时，Response.Write“foo”会更好。

从技术上讲，它们是一样的。

说到你的例子，Response.Write代码与＆amp;进行了很多字符串连接，即very slow in VBScript。此外，与Russell Myers said一样，它的标签方式与您的其他代码不同，这可能是无意的。

Answer 14

我同意Jason，现在更多的是.NET提供了一个MVC框架作为可怕的Web Form / Postback / ViewState .NET的替代品。

也许是因为我是老式的经典ASP / HTML / JavaScript而不是VB桌面应用程序程序员，这让我不能理解“网络形式的方式？”但是我很高兴我们似乎完全循环并回到Jason所指的方法。

考虑到这一点，我总是选择一个包含您的模型/逻辑和＆lt;％=％＆gt;的包含页面。你的标记，有效模板HTML“视图”。您的HTML将更具“可读性”，并且您的逻辑与经典ASP允许的分离;你用这块石头杀死了几只鸟。

Answer 15

如果您需要编写和维护Classic ASP应用程序，您应该查看免费的KudzuASP模板引擎。

它能够进行100％的代码和HTML分离，并允许原始asp页面的条件内容，变量替换，模板级控制。 If-Then-Else，Try-Catch-Finally，Switch-Case和其他结构标签以及基于asp页面或动态可加载库（asp代码文件）的自定义标签结构标签可嵌入其他结构中标记到任何所需的级别。

自定义标记和标记库易于编写，可以包含在asp页面的代码级别中，也可以在模板级别使用include标记。

可以通过在母版页级别调用模板引擎并为任何内部内容利用第二个子模板引擎来编写母版页。

在KudzuASP中，您的asp页面仅包含代码，创建模板引擎，设置初始条件并调用模板。该模板包含HTML布局。一旦asp页面调用模板，它就会变成一个事件驱动的资源，完全由模板的评估和它包含的结构驱动。

Response.Write vs＆lt;％=％＆gt;

15 个答案: