Response.Write vs <% =% >

Question

Gardez à l'esprit que ceci concerne asp classique

Quel est le meilleur, tout le code HTML contenu dans les déclarations Response.Write ou l'insertion de variables dans du code HTML via <% =% > ;.
P.ex.

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>

Je demande principalement, du point de vue des performances, quel impact sur le serveur aura le moins d'impact lorsque plusieurs variables seront insérées?

S'il n'y a pas de différences techniques, quels sont les arguments de l'un contre l'autre?

Answer 1

Premièrement, le facteur le plus important à prendre en compte est la facilité de maintenance. Vous pouvez acheter une batterie de serveurs avec l'argent et le temps que vous perdriez sinon à déchiffrer un site Web désordonné pour le maintenir.

Dans tous les cas, peu importe. En fin de compte, tout ce que fait ASP, c'est simplement exécuter un script! L'analyseur ASP prend la page et transforme <% = expression% > en appels de script directs. Chaque bloc HTML contigu devient un appel géant en Response.Write . . Le script résultant est mis en cache et réutilisé à moins que la page ne soit modifiée sur le disque, ce qui entraîne le recalcul du script en cache.

À présent, une trop grande utilisation de <% =% > conduit à la version moderne de "code spaghetti": la redoutable soupe aux balises "Tag soup". Vous ne serez pas capable de faire des têtes ou des queues de la logique. D'autre part, l'utilisation excessive de Response.Write signifie que vous ne pourrez jamais voir la page tant qu'elle ne sera pas rendue. Utilisez <% =% > pour tirer le meilleur parti des deux mondes.

Ma première règle est de faire attention à la proportion de "texte variable". vers "texte statique".

Si vous n'avez que quelques emplacements avec du texte variable à remplacer, la syntaxe <% =% > est très compacte et lisible. Toutefois, lorsque le <% =% > commence à s'accumuler, ils masquent de plus en plus le code HTML et, en même temps, le code HTML masque de plus en plus votre logique. En règle générale, une fois que vous commencez à prendre des boucles, vous devez vous arrêter et basculer vers Response.Write`.

Il n'y a pas beaucoup d'autres règles strictes et rapides. Vous devez choisir pour votre page (ou section de page) celle qui est la plus importante ou naturellement plus difficile à comprendre ou plus facile à casser: votre logique ou votre code HTML? C'est généralement l'un ou l'autre (j'ai vu des centaines de cas des deux)

Si votre logique est plus critique, vous devriez peser davantage vers Response.Write ; cela fera ressortir la logique. Si votre code HTML est plus critique, privilégiez <% =% > , ce qui rendra la structure de la page plus visible.

Parfois, j’ai dû écrire les deux versions et les comparer côte à côte pour décider laquelle est la plus lisible; c'est un dernier recours, mais faites-le pendant que le code est frais dans votre esprit et vous serez heureux trois mois plus tard, lorsque vous devrez apporter des modifications.

Answer 2

D'un point de vue des préférences personnelles, je préfère les <% =% > Je pense que cette méthode offre une meilleure séparation du contenu variable du contenu statique.

Answer 3

Mis à part les problèmes de lisibilité et de maintenabilité du code que d'autres ont abordés, votre question portait spécifiquement sur les performances lorsque vous devez insérer plusieurs variables. Je suppose donc que vous allez répéter plusieurs fois le même fragment de code. Dans ce cas, vous devriez obtenir les meilleures performances en utilisant un seul Response.Write sans concaténer toutes les nouvelles lignes:

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

Le navigateur n'a pas besoin des nouvelles lignes, des onglets ou de tout autre joli formatage pour analyser le code HTML. Si vous visez la performance, vous pouvez les supprimer. Vous réduirez également la taille de votre sortie HTML, ce qui accélérera le chargement des pages.

Dans le cas d'une seule variable, cela ne fait pas beaucoup de différence. Mais pour plusieurs variables, vous voulez minimiser le basculement de contexte entre HTML et ASP. Vous aurez un impact positif à chaque saut.

Pour améliorer la lisibilité lors de la construction d'une instruction plus longue, vous pouvez utiliser le caractère et les onglets de continuation de ligne VBScript de votre code source (mais pas la sortie) pour représenter la structure sans affecter vos performances:

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

Ce n'est pas aussi lisible que la version HTML, mais si vous déposez beaucoup de variables dans la sortie (c.-à-d. beaucoup de changements de contexte entre HTML et ASP), vous obtiendrez de meilleures performances.

Que les gains de performances en valent la peine ou qu'il soit préférable de faire évoluer votre matériel est une question distincte - et, bien sûr, ce n'est pas toujours une option.

Mise à jour: consultez les astuces 14 et 15 de cet article MSDN de Len Cardinal pour savoir comment améliorer les performances avec Response.Buffer et éviter le changement de contexte: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .

Answer 4

Beaucoup de réponses ici indiquent que les deux approches produisent le même résultat et que le choix en est un de style et de performance de codage. Il semble que son contenu statique en dehors de <%% > devient un seul Response.Write.

Toutefois, il serait plus exact de dire le code en dehors de <%% > est envoyé avec BinaryWrite.

Response.Write prend une chaîne Unicode et la code dans le Response.CodePage actuel avant de la placer dans la mémoire tampon. Aucun codage de ce type n'a lieu pour le contenu statique d'un fichier ASP. Les caractères extérieurs à <%% > sont vidés octet pour octet dans le tampon.

Par conséquent, lorsque Response.CodePage est différent de CodePage utilisé pour enregistrer le fichier ASP, les résultats des deux approches peuvent différer.

Par exemple, disons que ce contenu est enregistré dans une page de codes 1252 standard: -

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

Le premier paragraphe est incompréhensible, car £ ne sera pas envoyé à l'aide du codage UTF-8, le second convient, car la chaîne Unicode fournie est codée en UTF-8.

Par conséquent, du point de vue des performances, l’utilisation de contenu statique est préférable car elle n’a pas besoin d’être encodée, mais il faut être prudent si la page de code enregistrée diffère de la page de code de sortie. Pour cette raison, je préfère enregistrer sous UTF-8, inclure <% @ codepage = 65001 et définir Response.Charset = "UTF-8".

Answer 5

Je préfère les <% =% > méthode dans la plupart des situations pour plusieurs raisons.

1. Le code HTML est exposé à l'EDI afin qu'il peut être traité en vous donnant info-bulles, fermeture de balises, etc.
2. Maintien de l’indentation dans la HTML de sortie est plus facile qui peut être très utile pour retravailler la mise en page.
3. Nouvelles lignes sans ajouter vbCrLf sur tout et encore pour revoir la source de sortie.

Answer 6

Le format de la réponse rendra le code HTML comme suit:

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

En conséquence, non seulement les moyens de produire votre code seront illisibles, mais le résultat sera également mal indexé. Tenez-vous-en à l’autre option.

Answer 7

Je préfère <% =% > uniquement parce que cela facilite le développement de Javascript. Vous pouvez écrire du code qui référence vos contrôles comme ceci

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

Je peux ensuite utiliser ce contrôle comme je le souhaite dans mon code javascript sans avoir à me soucier des identifiants codés en dur.

Response.Write peut casser du code ASP.NET AJAX à certaines occasions. Par conséquent, j’essaie de l’éviter sauf si je l’utilise pour le rendu de choses spécifiques dans des contrôles personnalisés.

Answer 8

J'essaie d'utiliser le paradigme MVC en utilisant ASP / PHP. Cela rend les choses plus faciles à maintenir, à ré-architecturer, à développer. À cet égard, j'ai tendance à avoir une page qui représente le modèle. Il s’agit principalement de VB / PHP et définit vars pour une utilisation ultérieure dans la vue. Il génère également des morceaux de HTML lors de la mise en boucle pour une inclusion ultérieure dans la vue. Ensuite, j'ai une page qui représente la vue. C’est principalement du HTML rempli de <% =% > Mots clés. Le modèle est #include -d dans la vue et c'est parti. La logique du contrôleur est généralement effectuée en JavaScript dans une troisième page ou côté serveur.

Answer 9

Mon ASP classique est rouillé, mais:

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

Ceci est exécuté tel quel. Ceci, cependant:

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

entraîne:

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

Où \ r \ n est un vbCrLf

Donc techniquement, le second est plus rapide. CEPENDANT, la différence serait mesurée en millisecondes, donc je ne m'en inquiéterais pas. Je serais plus préoccupé par le fait que le premier est quasiment impossible à maintenir (surtout par un développeur HTML-UI), alors que le second est trivial à maintenir.

props à @Euro Micelli - la maintenance est la clé (c’est aussi pourquoi des langages comme Ruby, Python et, dans le passé (bien que ...), C # et Java se sont mutuellement démêlés contre C, C ++ et Assembly. conservez le code, ce qui est bien plus important que de gagner quelques minutes sur un chargement de page.

Bien sûr, C / C ++, etc. ont leur place ... mais ce n’est pas ça. :)

Answer 10

<% =% > et le reste est étendu à Response.Write () , de sorte que ce sera la même chose à la fin.

Answer 11

Il n'y a aucune amélioration des performances en passant à Response.Write, et la lecture et la maintenance à l'aide de la notation de raccourci peuvent être plus rapides.

Answer 12

Vous devez encadrer ces questions en termes de réutilisation de code et de maintenabilité du code (ou lisibilité). Il n’ya vraiment aucun gain de performance de toute façon.

Answer 13

<% = Bazify ()% > est utile lorsque vous générez du HTML à partir d'une expression courte insérée dans du HTML .

Response.Write "foo" est préférable lorsque vous devez créer du HTML en ligne avec beaucoup de code .

Techniquement, ce sont les mêmes.

Cependant, à propos de votre exemple, le code Response.Write effectue beaucoup de concaténation de chaînes avec & amp ;, qui est très lent dans VBScript . En outre, comme Russell Myers a déclaré , il n'est pas mis en onglet de la même manière que votre autre code, ce qui peut être involontaire. .

Answer 14

Je suis d'accord avec Jason , d'autant plus que .NET propose désormais une infrastructure MVC. affreux formulaire Web / Postback / ViewState .NET a commencé avec.

Peut-être que c’est peut-être parce que j’étais un classique classique de la vieille école, ASP / HTML / JavaScript, et non un programmeur d’applications de bureau VB, qui ne me permettait tout simplement pas de grokk "La voie du formulaire Web?" mais je suis tellement heureux que nous semblons être en train de boucler la boucle et de revenir à une méthodologie telle que Jason fait référence à. / p>

Dans cet esprit, je choisirais toujours une page incluse contenant votre modèle / logique et <% =% > jetons au sein de votre modèle HTML "efficacement". Votre code HTML sera plus "lisible" et votre logique séparée autant que l'ASP classique le permet; vous tuez quelques oiseaux avec cette pierre.

Answer 15

Si vous devez écrire et gérer une application Classic ASP, consultez le moteur de gabarit gratuit KudzuASP.

Il est capable de séparer à 100% le code et le code HTML et autorise le contenu conditionnel, la substitution de variable et le contrôle au niveau du modèle de la page asp d'origine. If-Then-Else, Try-Catch-Finally, Switch-Case et d'autres balises structurelles sont également disponibles, ainsi que des balises personnalisées basées sur la page asp ou dans des bibliothèques à chargement dynamique (fichiers de code asp). Des balises structurelles peuvent être incorporées à d'autres structures. balises à n'importe quel niveau désiré.

Les balises et bibliothèques de balises personnalisées sont faciles à écrire et peuvent être incluses au niveau du code de la page asp ou à l’aide d’une balise include au niveau du modèle.

Les pages maîtres peuvent être écrites en appelant un moteur de gabarit au niveau de la page maître et en exploitant un deuxième moteur de gabarit enfant pour tout contenu interne.

Dans KudzuASP, votre page asp ne contient que du code, crée le moteur de modèle, définit les conditions initiales et appelle le modèle. Le modèle contient une disposition HTML. Une fois que la page asp appelle le modèle, elle devient une ressource gérée par les événements, entièrement guidée par l’évaluation du modèle et de la structure qu’il contient.