Response.Write vs <% =%>

Question

Unter Berücksichtigung dieses ist für klassischen Asp

Was ist besser, alle HTML darin enthaltenen Response.Write-Anweisungen oder Variablen in HTML einfügen über <% =%>.
Eg

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>

Ich bin in erster Linie von einem Performance-Sicht zu fragen, in dem die am wenigsten Server auswirken wird, wenn mehrere Variablen einfügen?

Wenn es keine technischen Unterschiede, was die Argumente für einen über die andere sind?

Answer 1

Zuerst Der wichtigste Faktor Sie suchen sollten, ist eine einfache Wartung. Sie könnten eine Serverfarm mit dem Geld und Zeit kaufen Sie anders, indem er entziffern eine schmutzige Website verschwenden würden es aufrecht zu erhalten.

Auf jeden Fall spielt es keine Rolle. Am Ende des Tages alle ASP tut, ist auszuführen, nur ein Skript! Der ASP-Parser nimmt die Seite und verwandelt <%= expression %> in direkten Skript ruft, und jeder zusammenhängenden Block von HTML wird ein Riesen-Aufruf Response.Write. Das resultierende Skript wird zwischengespeichert und es sei denn, die Seite Änderungen auf der Festplatte wiederverwendet, die die im Cache gespeicherte Skript neu berechnet werden verursacht.

Nun zu viel Einsatz von <%= %> führt zur modernen Version von „Spaghetti-Code“: die gefürchtete „Tag Suppe“. Sie werden nicht in der Lage, Kopf oder Zahl der Logik zu machen. Auf der anderen Seite, zu viel Einsatz von Response.Write heißt, dass Sie nie die Seite, um zu sehen an alle in der Lage sein, bis er macht. Verwenden Sie <%= %> bei Bedarf das Beste aus beiden Welten zu erhalten.

Meine erste Regel ist, die Aufmerksamkeit auf den Anteil der „variablen Text“ zu zahlen „statischen Text“.

Wenn Sie nur ein paar Plätze mit variablen Text haben zu ersetzen, ist die <%= %> Syntax sehr kompakt und lesbar. Da jedoch der <%= %> Start zu sammeln, sie mehr und mehr von der HTML verschleiern und zugleich die HTML verschleiert mehr und mehr von Ihrer Logik. Als allgemeine Regel gilt, wenn Sie über Schleifen Beginn der Einnahme, müssen Sie Response.Write` stoppen und zu wechseln.

Es gibt nicht viele andere harte und schnelle Regeln. Sie benötigen für Ihre Seite (oder Abschnitt der Seite), die ein noch wichtiger ist, oder natürlich schwerer zu verstehen, oder einfacher zu brechen, um zu entscheiden: Ihre Logik oder Ihre HTML? Es ist in der Regel ein oder die andere (ich habe Hunderte von Fällen von beiden gesehen)

Wenn Sie Logik kritischer ist, sollten Sie mehr in Richtung Response.Write Gewicht; es wird die Logik abheben. Wenn Sie HTML-kritischer ist, bevorzugt <%= %>, die die Seitenstruktur sichtbar machen.

Manchmal habe ich beiden Versionen schreiben und vergleichen sie Seite an Seite zu entscheiden, welches besser lesbar ist; es ist ein letzter Ausweg, aber es tun, während der Code im Kopf frisch ist, und Sie werden drei Monate später froh sein, wenn Sie Änderungen vornehmen müssen.

Answer 2

Von der persönlichen Vorliebe Sicht ziehe ich die <% =%> Methode, wie ich glaube, es eine bessere Trennung variable Inhalte von statischen Inhalten bereitstellt.

Answer 3

Abgesehen von Fragen der Code Lesbarkeit / maintainibility die andere angesprochen haben, war Ihre Frage speziell über die Leistung, wenn Sie mehrere Variablen einfügen müssen - so nehme ich an Sie gehen so etwas wie Ihr Code-Fragment mehrere Male zu wiederholen. In diesem Fall sollten Sie die beste Leistung erhalten, indem ein einzelnes Response.Write verwenden, ohne alle der Zeilenumbrüche verketten:

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

Der Browser muss nicht die Zeilenumbrüche oder die Tabs oder andere hübsche Formatierung der HTML zu analysieren. Wenn Sie für die Leistung gehen, können Sie alle diese entfernen. Sie werden auch Ihre HTML-Ausgabe kleiner machen, die Ihnen schnelle Ladezeiten geben wird.

Im Fall einer einzigen Variablen, ist es nicht wirklich viel Unterschied machen. Aber für mehrere Variablen, möchten Sie den Kontext minimieren zwischen HTML und ASP Schalt - Sie einen Treffer aus einer für jeden Sprung nehmen werden auf die anderen

.

mit Lesbarkeit helfen, wenn eine längere Anweisung bauen Sie den VBScript-Zeilenfortsetzungs charcter und Registerkarten im Quellcode verwenden können (aber die Ausgabe nicht), um die Struktur zu repräsentieren, ohne Ihre Leistung zu schlagen:

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

Es ist nicht so lesbar wie die HTML-Version, aber wenn Sie eine Menge von Variablen in den Ausgang fallen (dh eine Menge Zusammenhang zwischen HTML und ASP schaltend), werden Sie eine bessere Leistung sehen.

Ob die Performance-Gewinne sind es wert, oder ob Sie wäre besser dran, die Skalierung der Hardware ist eine andere Frage -. Und, natürlich, es ist nicht immer eine Option

Update: siehe Tipp 14 und 15 in diesem MSDN-Artikel von Len Cardinal für Informationen über die Performance mit Response.Buffer zu verbessern und die Vermeidung von Kontextwechseln: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .

Answer 4

Viele der Antworten hier zeigen, dass die beiden Ansätze die gleiche Leistung erzeugen und dass die Wahl ist eine Art und Leistung der Codierung. Sein scheint seine angenommen, dass statische Inhalte außerhalb von <%%> ein einzelnes Response.Write wird.

Allerdings wäre es genauer der Code außerhalb zu sagen <%%> wird mit Binary gesendet.

Response.Write nimmt eine Unicode-Zeichenfolge und codiert sich das aktuelle Response.CodePage, bevor es in dem Puffer platziert. Eine solche Codierung erfolgt für die statische Inhalte in einer ASP-Datei. Die Zeichen außerhalb <%%> sind wörtlich Byte für Byte in den Puffer geworfen.

So, wo die Response.CodePage ist anders als die Codepage, die verwendet wurde das ASP zu speichern, die Ergebnisse der beiden Ansätze Datei kann unterschiedlich sein.

Zum Beispiel kann sagen, ich habe diesen Inhalt in einer Standard-Codepage 1252 gespeichert: -

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

Der erste Absatz ist verstümmelt, da die £ nicht UTF-8-Kodierung gesendet wird, die zweite ist in Ordnung, da die mitgelieferten Unicode-String in UTF-8 codiert wird.

Damit aus einer Perfomance Sicht statischen Inhalt verwendet, ist bevorzugt, da es nicht Codierung braucht aber Sorgfalt ist erforderlich, wenn die gespeicherte Code-Seite aus dem Ausgabecodepage unterscheidet. Aus diesem Grunde ziehe ich als UTF-8 zu speichern, schließen <% @ Codepage = 65001 und setzt Response.Charset = "UTF-8".

Answer 5

Ich ziehe die <% =%> Methode in den meisten Fällen aus mehreren Gründen.

1. Der HTML an den IDE ausgesetzt, so dass es können Sie verarbeitet werden, geben Tooltips, Tag schließen, etc.
2. Die Aufrechterhaltung Einzug in die Ausgabe HTML ist einfacher, die sein kann sehr hilfreich mit Nacharbeiten Layout.
3. Neue Linien ohne vbCrLf Anhängen auf alles und wieder für Ausgabequelle zu überprüfen.

Answer 6

Das Antwortformat wird HTML machen etwa so:

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

Als Ergebnis werden nicht nur die Mittel, um Ihren Code zu erzeugen unlesbar sein, aber das Ergebnis wird auch unangemessen Tabbed werden. Halten Sie mit der anderen Option.

Answer 7

ziehe ich <%= %> nur, weil es einfacher Javascript Entwicklung macht. Sie können Code schreiben, Ihre Steuerelemente wie diese verweist

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

Ich kann dann die steuern, jede mögliche Weise verwenden, die ich in meinem Javascript-Code möchte, ohne sich um die hart codierte IDs kümmern.

Response.Write kann einig ASP.NET AJAX-Code bei einigen Gelegenheiten brechen, damit ich versuche, es zu vermeiden, wenn es für die Wiedergabe bestimmte Dinge in benutzerdefinierten Steuerelemente verwendet wird.

Answer 8

Ich versuche, das MVC-Paradigma zu verwenden, wenn ASP / PHP zu tun. Es macht die Dinge am einfachsten zu pflegen, Wieder Architekten, erweitert auf. In dieser Hinsicht, neige ich dazu, eine Seite zu haben, der das Modell darstellt. Es ist vor allem VB / PHP und setzt Vars für die spätere Verwendung in der Ansicht. Es erzeugt auch große Stücke von HTML, wenn für eine spätere Aufnahme in der Ansicht Looping. Dann habe ich eine Seite, die die Ansicht vertritt. Das ist HTML meist mit <% =%> -Tags gespickt. Das Modell ist #include -d in der Ansicht und gehen Sie weg. Controller-Logik wird in der Regel in JavaScript in einer dritten Seite oder serverseitige getan.

Answer 9

Mein klassischer ASP ist rostig, aber:

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

Dies ist ausgeführt, wie sie ist. Dies ist jedoch:

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

Ergebnisse in:

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

Wo \ r \ n ein vbCrLf

Technisch gesehen ist der zweite schneller. Allerdings würde der Unterschied in einzelnen Millisekunden gemessen werden, also würde ich darüber keine Sorgen machen. Ich würde eher die Sorge, dass die obersten ziemlich viel ist wartbaren (va durch einen HTML-UI-Entwickler), wobei als die zweiten trivial zu erhalten.

Requisiten @Euro Micelli - Wartung ist der Schlüssel (die auch, warum Sprachen wie Ruby, Python ist, und in der Vergangenheit (tho noch ....) C # und Java traten Hintern über C, C ++ und Montage- Menschen konnten halten Sie den Code, der viel wichtiger ist, ein paar ms aus einer Seite zu laden, als Rasieren.

Natürlich, C / C ++ usw. haben ihren Platz .... aber das ist es nicht. :)

Answer 10

<%= %> und der Rest erweitert erhalten Response.Write() so ist es das gleiche am Ende.

Answer 11

Es gibt keine Leistungsverbesserung Umschaltung auf Response.Write, und es kann schneller zu lesen und verwalten die Verknüpfung Notation.

Answer 12

Sie sollten diese Fragen in Bezug auf die Wiederverwendung von Code und Code Wartbarkeit Rahmen (aka Lesbarkeit). Es ist wirklich so oder so keine Leistung erhalten.

Answer 13

<% = Bazify ()%> ist nützlich, wenn Sie HTML erzeugen aus einem kurzen Ausdruck inline mit einigen HTML .

Response.Write "foo" ist besser, wenn Sie einige HTML inline mit viel Code tun müssen.

Technisch sind sie gleich.

über Ihr Beispiel Sprechen, aber tut der Response.Write Code eine Menge von String-Verkettung mit &, das ist sehr langsam in VBScript . Auch, wie Russell Myers sagte , es ist nicht die gleiche Art und Weise wie Ihre anderen Code mit Registerkarten, die unbeabsichtigt sein könnte .

Answer 14

ich mit Jason einverstanden sind, um so mehr jetzt, dass .NET ist ein MVC-Framework als Alternative zu dem Angebot schrecklich Webformular / Postback / Viewstate .NET begann mit.

Vielleicht ist es, weil ich die alte Schule klassische ASP / HTML / JavaScript und keine VB-Desktop-Anwendung Programmierer war, die ich einfach nicht verursacht grokk „Der Weg der Web Form?“ aber ich bin so froh, dass wir scheinen Kreis zu gehen und zurück zu einer Methodik wie Jason bezieht.

In diesem Sinne würde ich immer eine eingeschlossene Seite enthält Ihr Modell / Logik und <% =%> Tokens innerhalb Ihrer effektiv Vorlage HTML wählen Sie „Ansicht“. Ihre HTML wird mehr „lesbar“ und Ihre Logik getrennt, so viel wie klassische ASP ermöglicht; Sie mit diesem Stein ein paar Vögel zu töten.

Answer 15

Wenn Sie sind verpflichtet, eine klassischer ASP-Anwendung zu schreiben und halten Sie das kostenlose KudzuASP Template-Engine heraus überprüfen sollten.

Es ist in der Lage 100% Code und HTML-Trennung und ermöglicht eine bedingten Inhalt, Variablensubstitution, Template-Ebene Steuerung der ursprünglichen ASP-Seite. If-Then-Else, Try-Catch-finally, Switch-Case und andere strukturellen Tags sind verfügbar sowie benutzerdefinierte Tags basierend auf der ASP-Seite oder in dynamisch ladbaren Bibliotheken (ASP-Code-Dateien) Struktur Tags in anderer Struktur eingebettet werden kann Tags zu jedem gewünschten Niveau.

Benutzerdefinierte Tags und Tag-Bibliotheken sind einfach zu schreiben und kann auf der ASP-Seite Code-Ebene enthalten sein oder mit einem Tag an der Vorlage Ebene umfassen.

Masterseiten können durch den Aufruf einer Template-Engine auf der Masterseite Ebene und nutzt ein zweites Kind Template-Engine für alle internen Inhalt geschrieben werden.

In KudzuASP Ihre ASP-Seite nur Code enthält, erstellt die Template-Engine, setzt Anfangsbedingungen und ruft die Vorlage. Die Vorlage enthält HTML-Layout. Sobald die ASP-Seite die Vorlage aufruft wird es dann eine angetriebene Ereignis Ressource vollständig durch die Auswertung der Vorlage getrieben und die Struktur, die es enthält.