Response.Write vs <% =%>
Gardant à l'esprit que c'est pour asp classique
Ce qui est mieux, tout le HTML contenu dans les instructions Response.Write ou l'insertion de variables dans HTML via <% =%>.
Par exemple
Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf
CONTRE
<table>
<tr>
<td class="someClass"><%= someVariable %></td>
</tr>
</table>
Je demande principalement du point de vue des performances qui aura le moins d'impact sur le serveur lorsqu'il y aura plusieurs variables à insérer?
S'il n'y a pas de différences techniques, quels sont les arguments en faveur de l'un par rapport à l'autre?
Premièrement, le facteur le plus important à considérer est la facilité d'entretien. Vous pourriez acheter une batterie de serveurs avec l'argent et le temps que vous perdriez autrement en ayant à déchiffrer un site Web en désordre pour le maintenir.
En tout cas, ça n'a pas d'importance. À la fin de la journée, tout ASP ne fait qu'exécuter un script! L'analyseur ASP prend la page et transforme <%= expression %> En appels de script directs, et chaque bloc contigu de code HTML devient un appel géant à Response.Write. Le script résultant est mis en cache et réutilisé à moins que la page ne change sur le disque, ce qui entraîne le recalcul du script mis en cache.
Maintenant, trop d'utilisation de <%= %> Conduit à la version moderne du "code spaghetti": la redoutable "soupe de tag". Vous ne serez pas en mesure de faire des têtes ou des queues de la logique. D'un autre côté, une utilisation excessive de Response.Write signifie que vous ne pourrez jamais voir la page du tout jusqu'à ce qu'elle s'affiche. Utilisez <%= %> Le cas échéant pour tirer le meilleur parti des deux mondes.
Ma première règle est de faire attention à la proportion de "texte variable" à "texte statique".
Si vous n'avez que quelques emplacements avec du texte variable à remplacer, la syntaxe <%= %> Est très compacte et lisible. Cependant, à mesure que les <%= %> Commencent à s'accumuler, ils obscurcissent de plus en plus le HTML et en même temps le HTML obscurcit 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 passer à Response.Write`.
Il n'y a pas beaucoup d'autres règles dures et rapides. Vous devez décider pour votre page particulière (ou section de la page) laquelle est la plus importante, ou naturellement plus difficile à comprendre, ou plus facile à briser: votre logique ou votre 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 plus 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.
D'un point de vue personnel, je préfère la méthode <% =%> car je pense qu'elle fournit un meilleur contenu variable de séparation du contenu statique.
Beaucoup de réponses ici indiquent que les deux approches produisent la même sortie et que le choix est celui du style de codage et des performances. Il semble que son contenu statique en dehors de <%%> devienne une réponse unique.
Cependant, il serait plus précis de dire que 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 le tampon. Aucun encodage de ce type n'a lieu pour le contenu statique dans un fichier ASP. Les caractères en dehors de <%%> sont vidés mot pour mot dans le tampon.
Par conséquent, lorsque le Response.CodePage est différent du CodePage qui a été utilisé pour enregistrer le fichier ASP, les résultats des deux approches peuvent différer.
Par exemple, disons que j'ai ce contenu 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 tronqué, car le £ ne sera pas envoyé en utilisant le codage UTF-8, le second est correct 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'encodage, mais il faut faire attention si la page de codes enregistrée diffère de la page de codes de sortie. Pour cette raison, je préfère enregistrer en UTF-8, inclure <% @ codepage = 65001 et définir Response.Charset = "UTF-8".
Laissant de côté les problèmes de lisibilité/maintenabilité du code que d'autres ont abordés, votre question portait spécifiquement sur les performances lorsque vous avez plusieurs variables à insérer - je suppose donc que vous allez répéter plusieurs fois quelque chose comme votre fragment de code. Dans ce cas, vous devriez obtenir les meilleures performances en utilisant une seule 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 ou des onglets ou de toute autre mise en forme jolie pour analyser le HTML. Si vous recherchez des performances, vous pouvez supprimer tout cela. Vous réduirez également votre sortie HTML, ce qui accélérera le chargement des pages.
Dans le cas d'une seule variable, cela ne fait pas vraiment de différence. Mais pour plusieurs variables, vous voulez minimiser le changement de contexte entre HTML et ASP - vous prendrez un coup pour chaque saut de l'un à l'autre.
Pour aider à la lisibilité lors de la création d'une instruction plus longue, vous pouvez utiliser le caractère de continuation de ligne VBScript et les onglets dans 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'est-à-dire beaucoup de changement de contexte entre HTML et ASP), vous verrez de meilleures performances.
Que les gains de performances en valent la peine ou que vous feriez mieux de faire évoluer votre matériel est une question distincte - et, bien sûr, ce n'est pas toujours une option.
Mise à jour: voir les astuces 14 et 15 dans cet article MSDN de Len Cardinal pour plus d'informations sur l'amélioration des performances avec Response.Buffer et sur l'évitement du changement de contexte: http://msdn.Microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .
Je préfère la méthode <% =%> dans la plupart des situations pour plusieurs raisons.
- Le HTML est exposé à IDE afin qu'il puisse être traité en vous donnant des info-bulles, la fermeture de balises, etc.
- Il est plus facile de maintenir l'indentation dans le code HTML de sortie, ce qui peut être très utile pour retravailler la présentation.
- Nouvelles lignes sans ajouter vbCrLf sur tout et encore pour revoir la source de sortie.
Mon classique ASP 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>
résulte en:
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. TOUTEFOIS, la différence serait mesurée en quelques millisecondes, donc je ne m'en inquiéterais pas. Je serais plus préoccupé par le fait que celui du haut est à peu près impossible à maintenir (en particulier par un développeur HTML-UI), alors que le second est trivial à maintenir.
accessoires à @Euro Micelli - la maintenance est la clé (c'est aussi pourquoi des langages comme Ruby, Python et dans le passé (tho encore ....) C # et Java kicked butt over C, C++ et Assembly - les humains pourraient maintenir le code, ce qui est bien plus important que de réduire de quelques ms le chargement d'une page.
Bien sûr, C/C++ etc ont leur place ... mais ce n'est pas ça. :)
Je préfère <%= %> uniquement parce qu'il facilite le développement de Javascript. Vous pouvez écrire du code qui référence vos contrôles comme celui-ci
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 ID codés en dur.
Response.Write peut casser du code ASP.NET AJAX à certaines occasions, donc j'essaye de l'éviter à moins de l'utiliser pour rendre des choses spécifiques dans des contrôles personnalisés.
J'essaie d'utiliser le paradigme MVC lors de l'exécution d'ASP/PHP. Cela rend les choses plus faciles à entretenir, à 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 des variables pour une utilisation ultérieure dans la vue. Il génère également des morceaux de HTML lors de la boucle pour une inclusion ultérieure dans la vue. Ensuite, j'ai une page qui représente la vue. C'est principalement du HTML parsemé de balises <% =%>. Le modèle est #include -d dans la vue et c'est parti. La logique du contrôleur se fait généralement en JavaScript sur une troisième page ou côté serveur.
Le format de réponse rendra HTML comme ceci:
<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 tabulé de manière inappropriée. Restez avec l'autre option.
<% = Bazify ()%> est utile lorsque vous générez du HTML à partir d'une expression courte en ligne avec du HTML .
Response.Write "foo" est meilleur lorsque vous devez en faire HTML en ligne avec beaucoup de code .
Techniquement, ce sont les mêmes.
Parlant de votre exemple, cependant, le code Response.Write fait beaucoup de concaténation de chaînes avec &, ce qui est très lent dans VBScript . De plus, comme Russell Myers a dit , il n'est pas tabulé de la même manière que votre autre code, ce qui pourrait être involontaire.
Je suis d'accord avec Jason , d'autant plus maintenant que .NET propose un framework MVC comme alternative à ce terrible formulaire Web/Postback/ViewState .NET a commencé avec.
C'est peut-être parce que j'étais un classique ASP/HTML/JavaScript classique et pas un VB programmeur d'applications de bureau qui m'a fait juste ne pas grokk "The Way of the Web Form?" Mais je suis si heureux que nous semblions faire le tour complet et revenir à une méthodologie comme Jason fait référence.
Dans cet esprit, je choisirais toujours une page incluse contenant votre modèle/logique et <% =%> jetons dans votre "vue" HTML de modèle. Votre HTML sera plus "lisible" et votre logique sera aussi séparée que classique ASP permet; vous tuez quelques oiseaux avec cette pierre.
<%= %> Et le reste est étendu à Response.Write() donc c'est la même chose à la fin.
Il n'y a pas d'amélioration des performances en passant à Response.Write, et il peut être plus rapide de lire et de maintenir à l'aide de la notation de raccourci.
Si vous devez écrire et gérer une application Classic ASP, vous devez consulter le moteur de modèle KudzuASP gratuit.
Il est capable de séparer le code à 100% et HTML et permet le contenu conditionnel, la substitution de variables, le contrôle au niveau du modèle de la page asp d'origine. If-Then-Else, Try-Catch-Final, Switch-Case et d'autres balises structurelles sont disponibles ainsi que des balises personnalisées basées sur la page asp ou dans des bibliothèques chargeables dynamiquement (fichiers de code asp) Les balises structurelles peuvent être incorporées dans d'autres structures balises à n'importe quel niveau souhaité.
Les balises personnalisées et les bibliothèques de balises sont faciles à écrire et peuvent être incluses au niveau du code de la page asp ou en utilisant une balise include au niveau du modèle.
Les pages maîtres peuvent être écrites en invoquant un moteur de modèle au niveau de la page maître et en exploitant un deuxième moteur de modèle enfant pour tout contenu interne.
Dans KudzuASP, votre page asp contient uniquement 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 alors une ressource événementielle entièrement pilotée par l'évaluation du modèle et de la structure qu'il contient.
Vous devez cadrer ces questions en termes de réutilisation de code et de maintenabilité de code (aka lisibilité). Il n'y a vraiment aucun gain de performance dans les deux cas.