Response.Write vs <%=%>

请记住这是经典的asp

哪个更好,所有HTML包含在Response.Write语句中或通过<%=%>将变量插入HTML.
例如

Response.Write "" & vbCrlf
Response.Write "" &vbCrLf
Response.Write "" & vbCrLf
Response.Write "" & vbCrLf
Response.Write "
" & someVariable & "
" & vbCrLf

VS

  

     
<%= someVariable %>
  

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

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

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

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

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

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

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

没有其他许多硬性规定.您需要决定哪个页面(或页面部分)哪个更重要,或者更容易理解,或者更容易破解:您的逻辑或HTML？它通常是一个或另一个(我见过两百个案例)

如果你的逻辑更重要,你应该更加重视Response.Write; 它将使逻辑脱颖而出.如果你的HTML更为关键,那么<%= %>这将使页面结构更加明显.

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

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

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

Response.Write "
" & someVar & "
"

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

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

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

Response.Write "" _
        & "" _
            & "" _
        & "" _
        & "" _
            & "" _
        & "" _
        & "" _
            & "" _
        & "" _
    & "
" & someVar & "
" & anotherVar & "
" & andSoOn & "
"

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

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

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

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

但是,将<%%>外部的代码与BinaryWrite一起发送会更准确.

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

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

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

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

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

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