asp classiC语言 Response.Write vs <%= %>

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

与

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

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

如果没有技术差异，那么一个比另一个的论据是什么？

首先，您应该考虑的最重要因素是易于维护。你可以用金钱和时间购买一个服务器场，否则你必须破译一个混乱的网站来维护它。

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

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

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

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

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

之）

如果你的逻辑更关键，你应该更偏重Response.Write;这将使逻辑脱颖而出。如果你的HTML更关键，请偏爱<%= %>，这将使页面结构更加可见。

有时我不得不编写两个版本并并排比较它们，以确定哪个版本更具可读性;这是最后的手段，但是在代码记忆犹新的时候做，三个月后当你必须进行更改时，你会很高兴。

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

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

但是，更准确地说，<% %> 之外的代码是使用 BinaryWrite 发送的。

Response.Write 采用一个 Unicode 字符串并将其编码到当前的 Response.CodePage，然后再将其放入缓冲区。不会对 ASP 文件中的静态内容进行此类编码。 <% %> 之外的字符将逐字节逐字节转储到缓冲区中。

因此，如果 Response.CodePage 与用于保存 ASP 文件的代码页不同，则这两种方法的结果可能会有所不同。

例如，假设我将此内容保存在标准 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"。

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

在大多数情况下

，我更喜欢<%= %>方法，原因有几个。

HTML 将公开给 IDE，因此它可以被处理给你工具提示、标签关闭等
在输出HTML更容易，可以是对返工布局非常有帮助。
不附加 vbCrLf 的新行在所有内容上，并再次查看输出源。

响应格式将呈现如下 HTML：

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

因此，不仅生成代码的方法不可读，而且结果也会被不恰当地选项卡化。坚持使用其他选项。

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

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

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

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

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

我的经典 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>rn<tr>rn<td class="someClass">"
Response.Write someVariable
Response.Write "</td>rn</tr>rn</table>"

其中 \r 是 vbCrLf

所以从技术上讲，第二个更快。但是，差异将以一毫秒为单位测量，所以我不会担心。我更担心的是顶部几乎无法维护（尤其是由 HTML-UI 开发人员维护），而第二个维护起来微不足道。

道具@Euro米切利 - 维护是关键（这也是为什么像Ruby，Python这样的语言，以及过去（现在仍然......）。C#和Java超越了C，C++和汇编 - 人类可以维护代码，这比减少页面加载几毫秒更重要。

当然，C/C++等也有自己的位置。但事实并非如此。:)

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

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

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

<%=Bazify（）%> 在从与某些 HTML 内联的短表达式生成 HTML 时很有用。

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

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

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

我同意Jason的观点，现在.NET提供了一个MVC框架作为.NET开始的糟糕的Web Form/Postback/ViewState的替代方案。

也许是因为我是老派的经典ASP/HTML/JavaScript而不是VB桌面应用程序程序员，导致我只是不去摸索"Web Form的方式？"但我很高兴我们似乎正在绕一圈，回到Jason提到的方法论。

考虑到这一点，我总是选择一个包含模型/逻辑的页面，并在有效的模板 HTML "视图中"<%= %> 标记。您的 HTML 将更具"可读性"，并且您的逻辑将尽可能多地分离经典 ASP;你用那块石头杀死了几只鸟。

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

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

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

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

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

相关内容

最新更新

热门标签：