Response.Write vs <% =% >

Question

Tenendo presente questo è per asp classico

Che è meglio, tutto l'HTML contenuto in Response.Write Dichiarazioni o l'inserimento di variabili in HTML tramite <% =% > ;.
Ad esempio

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>

Chiedo principalmente dal punto di vista delle prestazioni in cui avrà il minimo impatto sul server quando ci sono più variabili da inserire?

Se non ci sono differenze tecniche, quali sono gli argomenti l'uno rispetto all'altro?

Answer 1

Innanzitutto, il fattore più importante da considerare è la facilità di manutenzione. È possibile acquistare una server farm con i soldi e il tempo che altrimenti si perderebbe dover decifrare un sito Web disordinato per mantenerlo.

In ogni caso, non importa. Alla fine, tutto ciò che ASP fa è semplicemente eseguire uno script! Il parser ASP prende la pagina e trasforma <% = expression% > in chiamate di script dirette e ogni blocco contiguo di HTML diventa una gigantesca chiamata a Response.Write . Lo script risultante viene memorizzato nella cache e riutilizzato a meno che la pagina non cambi sul disco, il che provoca il ricalcolo dello script memorizzato nella cache.

Ora, un uso eccessivo di <% =% > porta alla versione moderna di " spaghetti code " ;: il temuto " tag soup " ;. Non sarai in grado di fare la testa o la coda della logica. D'altra parte, l'uso eccessivo di Response.Write significa che non sarai mai in grado di vedere la pagina fino a quando non viene visualizzata. Usa <% =% > quando appropriato per ottenere il meglio da entrambi i mondi.

La mia prima regola è prestare attenzione alla proporzione di "testo variabile" a " testo statico " ;.

Se hai pochi punti con testo variabile da sostituire, la sintassi <% =% > è molto compatta e leggibile. Tuttavia, quando il <% =% > inizia ad accumularsi, oscurano sempre di più l'HTML e allo stesso tempo l'HTML oscura sempre di più la tua logica. Come regola generale, una volta che inizi a fare dei loop, devi fermarti e passare a Response.Write`.

Non ci sono molte altre regole rigide e veloci. Devi decidere per la tua pagina particolare (o sezione della pagina) quale è più importante, o naturalmente più difficile da capire, o più facile da rompere: la tua logica o il tuo HTML? Di solito è l'uno o l'altro (ho visto centinaia di casi di entrambi)

Se la tua logica è più critica, dovresti ponderare di più verso Response.Write ; farà risaltare la logica. Se il tuo HTML è più critico, preferisci <% =% > , che renderà più visibile la struttura della pagina.

A volte ho dovuto scrivere entrambe le versioni e confrontarle fianco a fianco per decidere quale è più leggibile; è l'ultima risorsa, ma fallo mentre il codice è fresco nella tua mente e sarai contento tre mesi dopo quando devi apportare modifiche.

Answer 2

Dal punto di vista delle preferenze personali preferisco il <% =% > secondo il mio metodo, fornisce una migliore separazione del contenuto variabile dal contenuto statico.

Answer 3

Lasciando da parte i problemi di leggibilità / manutenibilità del codice che altri hanno affrontato, la tua domanda riguardava in particolare le prestazioni quando hai più variabili da inserire, quindi presumo che ripeterai più volte qualcosa come il tuo frammento di codice. In tal caso, dovresti ottenere le migliori prestazioni utilizzando un'unica risposta. Scrivi senza concatenare tutte le nuove righe:

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

Il browser non ha bisogno delle newline o delle schede o di qualsiasi altra formattazione carina per analizzare l'HTML. Se hai intenzione di esibirti, puoi rimuoverli tutti. Riducerai anche il tuo output HTML, il che ti darà tempi di caricamento della pagina più rapidi.

Nel caso di una singola variabile, non fa molta differenza. Ma per più variabili, vuoi ridurre al minimo il cambio di contesto tra HTML e ASP: ti colpirai per ogni salto dall'una all'altra.

Per facilitare la leggibilità quando si crea un'istruzione più lunga, è possibile utilizzare il carattere e le schede di continuazione della linea VBScript nel codice sorgente (ma non l'output) per rappresentare la struttura senza compromettere le prestazioni:

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

Non è leggibile come la versione HTML, ma se si stanno trascinando molte variabili nell'output (ovvero molti cambi di contesto tra HTML e ASP), si vedranno prestazioni migliori.

Se valgono le prestazioni o se migliorerai il ridimensionamento dell'hardware è una domanda separata e, ovviamente, non è sempre un'opzione.

Aggiornamento: vedi i suggerimenti 14 e 15 in questo articolo MSDN di Len Cardinal per informazioni su come migliorare le prestazioni con Response.Buffer ed evitare il cambio di contesto: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .

Answer 4

Molte delle risposte qui indicano che i due approcci producono lo stesso output e che la scelta è di stile di codifica e prestazioni. Sembra che si ritiene che il contenuto statico al di fuori di <%% > diventa un singolo Response.Write.

Tuttavia sarebbe più preciso dire il codice al di fuori di <%% > viene inviato con BinaryWrite.

Response.Write accetta una stringa Unicode e la codifica nella Response.CodePage corrente prima di inserirla nel buffer. Nessuna codifica del genere ha luogo per il contenuto statico in un file ASP. I caratteri all'esterno di <%% > vengono scaricati byte testuali per byte nel buffer.

Quindi, quando Response.CodePage è diverso dalla CodePage utilizzata per salvare il file ASP, i risultati dei due approcci possono differire.

Ad esempio, supponiamo che questo contenuto sia stato salvato in una codepage standard 1252: -

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

Il primo paragrafo è confuso, poiché £ non verrà inviato utilizzando la codifica UTF-8, il secondo va bene perché la stringa Unicode fornita è codificata in UTF-8.

Quindi, dal punto di vista delle prestazioni, è preferibile utilizzare contenuto statico poiché non ha bisogno di codifica ma è necessario fare attenzione se la tabella codici salvata differisce dalla tabella codici di output. Per questo motivo preferisco salvare come UTF-8, includere <% @ codepage = 65001 e impostare Response.Charset = " UTF-8 " ;.

Answer 5

Preferisco <% =% > metodo nella maggior parte dei casi per diversi motivi.

1. L'HTML è esposto all'IDE così che può essere elaborato dandoti descrizioni comandi, chiusura tag, ecc.
2. Mantenimento del rientro in l'output HTML è più semplice quale può essere molto utile con rielaborare il layout.
3. Nuove righe senza aggiungere vbCrLf su tutto e ancora per rivedere la fonte di output.

Answer 6

Il formato di risposta renderà HTML in questo modo:

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

Di conseguenza, non solo i mezzi per produrre il tuo codice saranno illeggibili, ma il risultato verrà anche tabulato in modo inappropriato. Resta con l'altra opzione.

Answer 7

Preferisco <% =% > unicamente perché semplifica lo sviluppo di Javascript. Puoi scrivere codice che fa riferimento ai tuoi controlli in questo modo

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

Posso quindi utilizzare quel controllo come preferirei nel mio codice javascript senza dovermi preoccupare degli ID codificati.

Response.Write può rompere il codice AJAX ASP.NET in alcune occasioni, quindi provo ad evitarlo a meno che non lo usi per renderizzare cose specifiche nei controlli personalizzati.

Answer 8

Cerco di usare il paradigma MVC quando faccio ASP / PHP. Rende le cose più facili da mantenere, riprogettare, espandere. A tale proposito, tendo ad avere una pagina che rappresenta il modello. È principalmente VB / PHP e imposta vari per un uso successivo nella vista. Genera anche blocchi di HTML durante il looping per l'inclusione successiva nella vista. Quindi ho una pagina che rappresenta la vista. Questo è principalmente HTML disseminato di <% =% > tag. Il modello è #include -d nella vista e via. La logica del controller viene in genere eseguita in JavaScript in una terza pagina o lato server.

Answer 9

Il mio ASP classico è arrugginito, ma:

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

questo viene eseguito così com'è. Questo, tuttavia:

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

risulta in:

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

Dove \ r \ n è un vbCrLf

Quindi tecnicamente, il secondo è più veloce. TUTTAVIA, la differenza sarebbe misurata in singoli millisecondi, quindi non mi preoccuperei. Sarei più preoccupato che quello principale sia praticamente non mantenibile (specialmente da uno sviluppatore HTML-UI), dove come secondo è banale da mantenere.

puntelli a @Euro Micelli - la manutenzione è la chiave (ed è anche per questo che linguaggi come Ruby, Python, e in passato (anche se ancora ....) C # e Java davano il calcio a C, C ++ e Assembly - gli umani potevano mantenere il codice, che è molto più importante della rasatura di alcuni ms dal caricamento della pagina.

Naturalmente, C / C ++ ecc hanno il loro posto .... ma non è così. :)

Answer 10

<% =% > e il resto viene espanso in Response.Write () , quindi alla fine è lo stesso.

Answer 11

Non vi è alcun miglioramento delle prestazioni passando a Response.Write e può essere più veloce da leggere e mantenere utilizzando la notazione di scelta rapida.

Answer 12

Dovresti inquadrare queste domande in termini di riutilizzo del codice e manutenibilità del codice (ovvero la leggibilità). Non c'è davvero alcun miglioramento delle prestazioni in entrambi i casi.

Answer 13

<% = Bazify ()% > è utile quando stai generando HTML da una espressione breve in linea con un po 'di HTML .

Response.Write " foo " è meglio quando devi fare un po 'di HTML in linea con molto codice .

Tecnicamente, sono gli stessi.

Parlando del tuo esempio, tuttavia, il codice Response.Write fa molta concatenazione di stringhe con & amp ;, che è molto lento in VBScript . Inoltre, come ha detto Russell Myers , non è tabulato allo stesso modo dell'altro codice, il che potrebbe non essere intenzionale .

Answer 14

Sono d'accordo con Jason , tanto più ora che .NET offre un framework MVC in alternativa a quello terribile Web Form / Postback / ViewState .NET è iniziato con.

Forse è perché ero ASP / HTML / JavaScript classico della vecchia scuola e non un programmatore di applicazioni desktop VB che mi ha fatto semplicemente non grokk " The Way of the Web Form? " ma sono così contento che sembriamo andare al punto di partenza e tornare a una metodologia come Jason si riferisce.

Con questo in mente, sceglierei sempre una pagina inclusa contenente il tuo modello / logica e <% =% > token nella tua visualizzazione HTML " efficacemente del modello. " Il tuo HTML sarà più " leggibile " e la tua logica è separata quanto l'ASP classico consente; stai uccidendo un paio di uccelli con quella pietra.

Answer 15

Se ti viene richiesto di scrivere e gestire un'applicazione ASP classica, dai un'occhiata al motore di template KudzuASP gratuito.

È in grado di separare il codice e HTML al 100% e consente il contenuto condizionale, la sostituzione delle variabili, il controllo a livello di modello della pagina asp originale. Sono disponibili If-Then-Else, Try-Catch-Infine, Switch-Case e altri tag strutturali, nonché tag personalizzati basati nella pagina asp o in librerie caricabili dinamicamente (file di codice asp) I tag strutturali possono essere incorporati in altri elementi strutturali tag a qualsiasi livello desiderato.

I tag personalizzati e le librerie di tag sono facili da scrivere e possono essere inclusi a livello di codice della pagina asp o utilizzando un tag include a livello di modello.

Le pagine mastro possono essere scritte invocando un motore modello a livello di pagina mastro e sfruttando un secondo motore modello bambino per qualsiasi contenuto interno.

In KudzuASP la tua pagina asp contiene solo codice, crea il motore modello, imposta le condizioni iniziali e invoca il modello. Il modello contiene layout HTML. Una volta che la pagina asp invoca il modello, diventa quindi una risorsa guidata dagli eventi, completamente guidata dalla valutazione del modello e dalla struttura che contiene.