Response.Write vs <% =%>

Question

Tendo em mente esta é para asp clássico

O que é melhor, todos HTML contido dentro de instruções Response.Write ou inserir variáveis ??em HTML via <% =%>.
Por exemplo

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>

Estou pedindo principalmente do ponto de vista do desempenho, em que terá o impacto servidor menos quando há várias variáveis ??para inserir?

Se não há diferenças técnicas Quais são os argumentos para um sobre o outro?

Answer 1

Em primeiro lugar, o fator mais importante que você deve estar olhando é a facilidade de manutenção. Você poderia comprar um farm de servidores com o tempo e dinheiro que de outra forma desperdiçar por ter que decifrar um web site confuso para mantê-lo.

Em qualquer caso, não importa. No final do dia, tudo o ASP não é apenas executar um script! O analisador ASP leva a página, e transforma <%= expression %> em chamadas de script diretos, e cada bloco contíguo de HTML torna-se uma chamada de gigante para Response.Write. O script resultante é armazenado em cache e reutilizados menos que a página muda no disco, o que faz com que o script em cache de ser recalculado.

Agora, muito uso de leads <%= %> para a versão moderna do "código espaguete": o temido "Tag sopa". Você não será capaz de fazer cara ou coroa da lógica. Por outro lado, muito uso de Response.Write significa que você nunca será capaz de ver a página em tudo até que ele processa. Use <%= %> quando apropriado para obter o melhor dos dois mundos.

A minha primeira regra é prestar atenção na proporção de "texto variável" para "texto estático".

Se você tem apenas alguns lugares com texto variável para substituir, a sintaxe <%= %> é muito compacto e legível. No entanto, como o <%= %> começam a se acumular, elas obscurecem mais do HTML e, ao mesmo tempo, o HTML obscurece cada vez mais de sua lógica. Como regra geral, uma vez que você começar a tomar sobre loops, você precisa parar e mudar para Response.Write`.

Não há muitas outras regras duras e rápidas. Você precisa decidir para sua página particular (ou seção da página) qual é o mais importante, ou naturalmente mais difícil de entender, ou mais fácil de quebrar: sua lógica ou o seu HTML? É geralmente um ou o outro (eu vi centenas de casos de ambos)

Se você lógica é mais crítica, você deve pesar mais para Response.Write; ele vai fazer a lógica se destacam. Se você HTML é mais crítica, favor <%= %>, o que fará com que a estrutura da página mais visível.

Às vezes eu tive que escrever as duas versões e compará-los lado a lado para decidir qual é o mais legível; é um último recurso, mas fazê-lo enquanto o código está fresco em sua mente e você será feliz três meses mais tarde, quando você tem que fazer alterações.

Answer 2

A partir de um ponto de preferência de vista pessoal eu prefiro o método <% =%>, pois sinto que proporciona uma melhor conteúdo variável separação de conteúdo estático.

Answer 3

Deixando de lado questões de código readibility / maintainibility que os outros têm abordado, sua pergunta era especificamente sobre o desempenho quando você tem múltiplas variáveis ??para inserir - assim que eu supor que você vai estar a repetir algo como suas fragmento de código várias vezes. Nesse caso, você deve obter o melhor desempenho usando um único Response.Write sem concatenar todas as novas linhas:

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

O navegador não precisa de novas linhas ou as abas ou qualquer outro bem formatação para analisar o HTML. Se você estiver indo para o desempenho, você pode remover todos estes. Você também vai fazer a sua saída HTML menor, o que lhe dará mais rápido tempos de carregamento da página.

No caso de uma única variável, ele realmente não faz muita diferença. Mas para múltiplas variáveis, que pretende minimizar a troca de contexto entre HTML e ASP - você vai tomar uma batida para cada salto de um para o outro

.

Para ajuda com readibility quando a construção de uma declaração mais tempo, você pode usar a linha charcter VBScript continuação e guias em seu código fonte (mas não a saída) para representar a estrutura sem bater seu desempenho:

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>"

Não é tão legível como a versão HTML, mas se você está soltando uma série de variáveis ??para a saída (lote ou seja, um de troca de contexto entre HTML e ASP), você verá um melhor desempenho.

Se os ganhos de desempenho são vale a pena ou se você seria melhor fora de escalar o seu hardware é uma questão separada - e, é claro, não é sempre uma opção

.

Update: veja dicas 14 e 15 deste artigo MSDN por Len Cardinal para obter informações sobre como melhorar o desempenho com Response.Buffer e evitando troca de contexto: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .

Answer 4

Muitas das respostas aqui indicam que as duas abordagens produzem o mesmo resultado e que a escolha é um dos codificação de estilo e desempenho. Sua parece sua acreditava que fora conteúdo estático de <%%> se torna um único Response.Write.

No entanto, seria mais exato dizer o exterior código <%%> é enviado com BinaryWrite.

Response.Write leva uma seqüência de caracteres Unicode e codifica-lo para o Response.CodePage atual antes de colocá-lo no buffer. Nenhum tal codificação tem lugar para o conteúdo estático em um arquivo ASP. Os caracteres fora <%%> são despejados byte a byte textualmente na memória intermédia.

Assim onde o Response.CodePage é diferente do que o CodePage que foi usado para salvar o arquivo ASP os resultados das duas abordagens podem ser diferentes.

Por exemplo, digamos que eu tenho este conteúdo guardado em uma página 1252 código padrão: -

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

O primeiro parágrafo é ilegível, pois o £ não será enviado com codificação UTF-8, o segundo é bom porque a seqüência de caracteres Unicode fornecido é codificado para UTF-8.

Assim, de um ponto de vista perfomance com conteúdo estático é preferível, uma vez que não precisa de codificação, mas é necessário cuidado se a página de código salvos difere da página de códigos de saída. Por esta razão, eu prefiro salvar como UTF-8, incluem <% @ codepage = 65001 e definir Response.Charset = "UTF-8".

Answer 5

Eu prefiro o método <% =%> na maioria das situações, por diversas razões.

1. O HTML é exposta ao IDE de modo que ele pode ser processado dando-lhe dicas de ferramentas, fechamento tag, etc.
2. Manter recuo na HTML de saída é mais fácil que pode ser muito útil com retrabalhar layout.
3. Novas linhas sem acrescentar vbCrLf em tudo e novamente para rever fonte de saída.

Answer 6

O formato de resposta irá processar HTML assim:

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

Como resultado, não só os meios para produzir o seu código ser ilegível, mas o resultado também será tabulado de forma inadequada. Vara com a outra opção.

Answer 7

Eu prefiro <%= %> apenas porque torna o desenvolvimento Javascript mais fácil. Você pode escrever código que faz referência os controles como este

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

Eu posso usar esse controle de qualquer maneira que eu gostaria no meu código javascript sem ter que se preocupar com os IDs codificados duros.

Response.Write pode quebrar alguns códigos ASP.NET AJAX em algumas ocasiões, então eu tentar evitá-lo, a menos que usá-lo para renderização coisas específicas em controles personalizados.

Answer 8

Eu tento usar o paradigma MVC quando fazendo ASP / PHP. Isso torna as coisas mais fáceis de manter, re-arquiteto, expandir. A este respeito, eu tendem a ter uma página que representa o modelo. É principalmente VB / PHP e conjuntos vars para uso posterior na vista. Ele também gera pedaços de HTML quando looping para posterior inclusão no modo de exibição. Então eu tenho uma página que representa a visão. Isso é principalmente HTML salpicado com <% =%> tags. O modelo é -d #include na vista e você vai longe. lógica do controlador é normalmente feito em JavaScript em uma terceira página ou do lado do servidor.

Answer 9

Meu ASP clássico é enferrujado, mas:

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

Este é executado como está. Isso, no entanto:

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

resulta em:

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

Onde \ r \ n é um vbCrLf

Então, tecnicamente, o segundo é mais rápido. Entretanto, a diferença seria medido em milissegundos individuais, então eu não me preocuparia com isso. Eu estaria mais preocupado que a parte superior é praticamente insustentável (esp por um desenvolvedor HTML-UI), onde, como o segundo é trivial para manter.

adereços para @Euro Micelli - manutenção é a chave (que também é por isso que linguagens como Ruby, Python, e no passado (tho ainda ....) C # e Java chutou bunda mais de C, C ++ e os seres humanos recomendações da Assembleia poderia manter o código, que é muito mais importante do que raspar algumas ms fora de um carregamento da página.

Claro, C / C ++ etc têm o seu lugar .... mas não é isso. :)

Answer 10

<%= %> eo resto se expandiu para Response.Write() por isso é o mesmo no final.

Answer 11

Não há comutação de melhoria de desempenho para Response.Write, e pode ser mais rápido de ler e manter usando a notação de atalho.

Answer 12

Você deve enquadrar estas questões em termos de reutilização de código e manutenção de código (aka legibilidade). Não há realmente nenhum ganho de desempenho de qualquer forma.

Answer 13

<% = Bazify ()%> é útil quando você está gerando HTML a partir de um curto em linha expressão com algum HTML .

Response.Write "foo" é melhor quando você precisa fazer alguma HTML em linha com um monte de código .

Tecnicamente, eles são os mesmos.

Falando sobre o seu exemplo, porém, o código Response.Write faz um monte de concatenação com &, que é muito lento em VBScript . Além disso, como Russell Myers disse , não é tabulada da mesma forma que o seu outro código, que pode ser não intencional .

Answer 14

Eu concordo com Jason , mais agora que .NET está oferecendo um framework MVC como uma alternativa para que terrível web Form / postback / ViewState NET começou com.

Talvez seja porque eu estava old-school clássico ASP / HTML / JavaScript e não um aplicativo de área de trabalho programador VB que me levou a apenas não grokk "The Way of the Form Web?" mas eu estou muito feliz por nós parecem estar indo círculo completo e voltar para uma metodologia como Jason se refere.

Com isso em mente, eu sempre escolher uma página incluída contendo o seu modelo / lógica e <% =%> fichas dentro do seu, efetivamente modelo HTML "vista". Seu HTML será mais "legível" e sua lógica separadas, tanto quanto ASP clássico permite; você está matando um par de aves com essa pedra.

Answer 15

Se você é obrigado a escrever e manter uma aplicação ASP clássico que você deve verificar se o modelo de motor KudzuASP livre.

É capaz de código 100% e separação HTML e permite o conteúdo condicional, substituição de variáveis, controle de nível do modelo da página asp originais. If-Then-Else, try-catch-Finalmente, Switch-Case, e outras tags estruturais estão disponíveis, bem como tags personalizados com base na página ASP ou em bibliotecas carregadas dinamicamente (arquivos de código ASP) Tags Estruturais pode ser incorporado dentro de outro estrutural etiquetas para qualquer nível desejado.

tag personalizados e bibliotecas de tags são fáceis de escrever e pode ser incluído ao nível do código da página ASP ou usando um incluem tag no nível do modelo.

As páginas mestras podem ser escritos invocando um modelo de motor no nível da página mestre e alavancar um segundo modelo de motor criança por qualquer conteúdo interno.

Em KudzuASP sua página ASP contém apenas código, cria o modelo de motor, configura condições iniciais e invoca o modelo. O modelo contém HTML layout. Uma vez que a página ASP chama o modelo torna-se então um recurso orientado a eventos totalmente impulsionado pela avaliação do modelo e a estrutura que ele contém.