Response.Write vs <%= %>答案

【问题标题】：Response.Write vs <%= %>Response.Write vs <%= %>
【发布时间】：2015-01-29 00:38:15
【问题描述】：

请记住，这是针对 classic 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>

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

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

【问题讨论】：

存在技术差异，请看下面我的回答。

标签： asp-classic vbscript

【解决方案1】：

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

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

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

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

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

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

如果你的逻辑比较挑剔，你应该更重视Response.Write；它将使逻辑脱颖而出。如果您的 HTML 更挑剔，请支持<%= %>，这将使页面结构更加可见。

有时我不得不编写两个版本并并排比较它们以确定哪个更易读；这是不得已而为之的方法，但请在代码记忆犹新的情况下进行，三个月后当您必须进行更改时，您会很高兴。

【讨论】：

【解决方案2】：

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

【讨论】：

表示逻辑应该始终与业务逻辑分开。将 HTML 模板中的逻辑限制为简单的循环和条件，您会发现您的代码将更易于维护。

【解决方案3】：

这里的许多答案表明这两种方法产生相同的输出，并且选择是编码风格和性能之一。它似乎认为之外的静态内容成为单个 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，包括

【讨论】：

这个答案帮助我弄清楚事情的实际运作方式。谢谢@anthonywjones。此外，这里有一个网站用一些例子来解释它 -> example-code.com/asp/asp-codepages.asp

【解决方案4】：

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

【讨论】：

【解决方案5】：

在大多数情况下，我更喜欢方法有几个原因。

HTML 向 IDE 公开，因此它可以被处理给你工具提示、标签关闭等。
保持缩进输出 HTML 更容易，可以对重新设计布局很有帮助。
不附加 vbCrLf 的新行一遍又一遍地检查输出源。

【讨论】：

【解决方案6】：

响应格式会像这样呈现 HTML：

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

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

【讨论】：

【解决方案7】：

我更喜欢 <%= %> 仅仅是因为它使 Javascript 开发更容易。你可以像这样编写引用你的控件的代码

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

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

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

【讨论】：

【解决方案8】：

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

【讨论】：

【解决方案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++ 等都有它们的位置....但不是这样。 :)

【讨论】：

【解决方案10】：

<%= %> 和其余的扩展为 Response.Write() 所以最后是一样的。

【讨论】：

【解决方案11】：

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

【讨论】：

【解决方案12】：

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

【讨论】：

【解决方案13】：

在您从 与某些 HTML 内联的短表达式生成 HTML 时很有用。

Response.Write "foo" 当您需要使用大量代码执行一些 HTML 内联时会更好。

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

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

【讨论】：

【解决方案14】：

我同意Jason，更何况 .NET 提供了一个 MVC 框架来替代糟糕的 Web Form/Postback/ViewState .NET 一开始就使用了。

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

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

【讨论】：

【解决方案15】：

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

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

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

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

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

【讨论】：