asp-classic - Response.Write vs <%= %>

Question

请记住，这是针对经典 asp

更好的是，所有 HTML 都包含在 Response.Write 语句中或通过 <%= %> 将变量插入 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>

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

如果没有技术差异，那么两者之间的论点是什么？

score 43 · Accepted Answer

首先，您应该考虑的最重要因素是易于维护。您可以购买一个服务器场，而这些钱和时间会浪费在必须破译一个混乱的网站来维护它的情况下。

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

现在，过多的使用<%= %>导致了现代版的“意大利面条代码”：可怕的“标签汤”。您将无法确定逻辑的正面或反面。另一方面，过多地使用 Response.Write 意味着您将永远无法看到页面，直到它呈现。在适当的时候使用<%= %>以获得两全其美。

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

如果您只有几个地方需要替换可变文本，则<%= %>语法非常紧凑且易读。然而，随着<%= %>开始积累，它们模糊了越来越多的 HTML，同时 HTML 也越来越模糊了你的逻辑。作为一般规则，一旦您开始使用循环，您需要停止并切换到 Response.Write`。

没有很多其他硬性规定。您需要为您的特定页面（或页面的部分）决定哪个更重要，或者自然更难理解，或更容易破坏：您的逻辑还是您的 HTML？通常是其中之一（我见过数百个案例）

如果你的逻辑更关键，你应该更重视Response.Write; 它将使逻辑脱颖而出。如果您对 HTML 更挑剔，请青睐<%= %>，这将使页面结构更加明显。

有时我不得不编写两个版本并并排比较它们以确定哪个更易读；这是不得已而为之的办法，但要在代码记忆犹新的时候这样做，三个月后当你不得不进行更改时，你会很高兴。

score 13 · Accepted Answer

从个人喜好的角度来看，我更喜欢 <%= %> 方法，因为我觉得它可以更好地将变量内容与静态内容分开。

score 11 · Accepted Answer

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

然而，更准确的说法是 <% %> 之外的代码是通过 BinaryWrite 发送的。

Response.Write 采用 Unicode 字符串并将其编码为当前的 Response.CodePage，然后将其放入缓冲区。ASP 文件中的静态内容不会发生这种编码。<% %> 之外的字符逐个字节地转储到缓冲区中。

因此，如果 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，包括 <%@ codepage=65001 并设置 Response.Charset = "UTF-8"。

score 8 · Accepted Answer

撇开其他人已经解决的代码可读性/可维护性问题不谈，您的问题特别是关于当您要插入多个变量时的性能 - 所以我假设您将多次重复您的代码片段之类的东西。在这种情况下，您应该通过使用单个 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 之间的大量上下文切换），您会看到更好的性能。

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

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

score 3 · Accepted Answer

在大多数情况下，出于几个原因，我更喜欢 <%= %> 方法。

HTML 向 IDE 公开，以便对其进行处理，为您提供工具提示、标签关闭等。
在输出 HTML 中保持缩进更容易，这对重新设计布局非常有帮助。
没有在所有内容上附加 vbCrLf 的新行，并再次查看输出源。

score 2 · Accepted Answer

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

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

结果，不仅生成代码的方法不可读，而且结果也会被不恰当地标记。坚持另一个选项。

score 2 · Accepted Answer

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

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

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

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

我的经典 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++ 等都有它们的位置....但不是这样。:)

score 1 · Accepted Answer

1

<%= %>其余的被扩展为Response.Write()最终相同。

于 2008-09-30T01:53:13.793 回答

score 1 · Accepted Answer

切换到 Response.Write 并没有提高性能，并且使用快捷表示法可以更快地读取和维护。

score 1 · Accepted Answer

您应该根据代码重用和代码可维护性（也称为可读性）来构建这些问题。无论哪种方式，实际上都没有性能提升。

score 1 · Accepted Answer

<%=Bazify()%>在您从与一些 HTML 内联的短表达式生成 HTML 时很有用。

Response.Write "foo"当你需要用大量代码做一些 HTML 内联时会更好。

从技术上讲，它们是相同的。

但是，谈到您的示例， Response.Write 代码使用 & 进行了很多字符串连接，这在 VBScript 中非常慢。此外，就像Russell Myers 所说，它的标签方式与您的其他代码不同，这可能是无意的。

score 1 · Accepted Answer

我同意Jason的观点，尤其是现在 .NET 提供了一个 MVC 框架来替代最初使用的糟糕的 Web Form/Postback/ViewState。

也许是因为我是老派经典的 ASP/HTML/JavaScript，而不是 VB 桌面应用程序程序员，导致我无法理解“Web 表单的方式”？但我很高兴我们似乎正在走完整个循环，回到Jason所指的方法论。

考虑到这一点，我总是会在您的有效模板 HTML“视图”中选择包含您的模型/逻辑和 <%= %> 标记的包含页面。您的 HTML 将更具“可读性”，并且您的逻辑将与经典 ASP 允许的一样多；你用那块石头杀死了几只鸟。

score 1 · Accepted Answer

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

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

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

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

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

asp-classic - Response.Write vs <%= %>

15 回答 15

Related

Reference