Response.Write vs <%= %>

Question

Teniendo en cuenta esto es para ASP clásico

¿Qué es mejor, todo el HTML contenida dentro instrucciones Response.Write o variables inserción en HTML a través <% =%>.
Ej

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> 

Estoy pidiendo sobre todo desde el punto de vista del rendimiento en el que tendrá el menor impacto servidor cuando hay múltiples variables para insertar?

Si no hay diferencias técnicas cuáles son los argumentos a favor de uno sobre el otro?

Answer 1

En primer lugar, el factor más importante que debe mirar es la facilidad de mantenimiento. Podría comprar una granja de servidores con el dinero y el tiempo que de otra forma desperdiciaría al tener que descifrar un sitio web desordenado para mantenerlo.

En cualquier caso, no importa. ¡Al final del día, todo lo que hace ASP es simplemente ejecutar un script! El analizador ASP toma la página y transforma <%= expression %> en llamadas de scripts directos, y cada bloque contiguo de HTML se convierte en una llamada gigante al Response.Write. La secuencia de comandos resultante se almacena en caché y se reutiliza a menos que la página cambie en el disco, lo que hace que la secuencia de comandos en caché se vuelva a calcular.

Ahora, el uso excesivo de <%= %> conduce a la versión moderna del "código de spaghetti": la temida "sopa de etiquetas". No podrás hacer cara o cruz de la lógica. Por otro lado, demasiado uso de Response.Write significa que nunca podrás ver la página hasta que se muestre. Use <%= %> cuando sea apropiado para obtener lo mejor de ambos mundos.

Mi primera regla es prestar atención a la proporción de "texto de la variable" a "texto estático".

Si tiene unos pocos lugares con texto variable para reemplazar, la sintaxis <%= %> es muy compacta y fácil de leer. Sin embargo, cuando el <%= %> comienza a acumularse, oscurecen cada vez más el HTML y, al mismo tiempo, el código HTML oscurece cada vez más su lógica.Como regla general, una vez que comience a tomar bucles, debe parar y pasar a Response.Write`.

No hay muchas otras reglas duras y rápidas. Debe decidir por su página particular (o sección de la página) cuál es más importante, o más difícil de entender o más fácil de romper: su lógica o su HTML? Por lo general, es uno o el otro (he visto cientos de casos de ambos)

Si la lógica es más crítica, debe ponderar más hacia Response.Write; hará que la lógica se destaque. Si HTML es más crítico, favor de <%= %>, que hará que la estructura de la página sea más visible.

A veces he tenido que escribir ambas versiones y compararlas una al lado de la otra para decidir cuál es más legible; es un último recurso, pero hágalo mientras el código está fresco en su mente y se alegrará tres meses después cuando tenga que hacer cambios.

Answer 2

Desde el punto de vista de la preferencia personal prefiero el método <% =%> ya que siento que proporciona una mejor separación de contenidos variables de contenido estático.

Answer 3

<%= %> y el resto se amplía a Response.Write() así que es lo mismo al final.

Answer 4

No hay mejora en el rendimiento de conmutación a Response.Write, y puede ser más rápido de leer y mantener el uso de la notación de acceso directo.

Answer 5

Usted debe enmarcar estas preguntas en cuanto a la reutilización de código y de mantenimiento de código (también conocido como la legibilidad). Realmente no hay ganancia de rendimiento de ninguna manera.

Answer 6

El formato de respuesta va a representar HTML así:

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

Como resultado, no sólo va a los medios para producir su código ilegible, pero el resultado también serán pestañas de forma inapropiada. Quédate con la otra opción.

Answer 7

<% = Bazify()%> es útil cuando se generan HTML de una expresión corta en línea con algo de HTML.

Response.Write "foo" es mejor cuando se necesita hacer una cierta línea HTML con una gran cantidad de código.

Técnicamente, son lo mismo.

Hablando de su ejemplo, sin embargo, el código Response.Write hace una gran cantidad de concatenación de cadenas con &, que es very slow in VBScript. Además, al igual que Russell Myers said, no se etiqueta de la misma manera que su otro código, que podría ser involuntario.

Answer 8

Prefiero el método <% =%> en la mayoría de las situaciones por varias razones.

1. El HTML está expuesto al IDE de manera que pueda ser procesada que le da información sobre herramientas, etiqueta de cierre, etc.
2. El mantenimiento de la sangría en el código HTML de salida es más fácil que puede ser de gran ayuda con reelaboración diseño.
3. Líneas nuevas sin anexar vbCrLf en todo y nuevamente para revisar el origen de salida.

Answer 9

Prefiero <%= %> solo porque facilita el desarrollo de Javascript. Se puede escribir código que hace referencia a sus controles como esto

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

entonces puedo usar que el control de ninguna manera me gustaría en mi código JavaScript sin tener que preocuparse por las identificaciones codificadas duro.

Response.Write puede romper el código AJAX de ASP.NET en algunas ocasiones, así que trato de evitarlo a menos que lo use para representar cosas específicas en controles personalizados.

Answer 10

Dejando de lado los problemas de lectura/mantenimiento del código que otros han abordado, su pregunta era específicamente sobre el rendimiento cuando tiene que insertar múltiples variables, así que supongo que repetirá varias veces el fragmento de código. En ese caso, debe obtener el mejor rendimiento utilizando una sola respuesta.Escribir sin concatenación de todos los saltos de línea:

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

El navegador no necesitará los saltos de línea o las fichas o cualquier otro formato bastante para analizar el código HTML. Si busca rendimiento, puede eliminar todos estos. También reducirá su salida de HTML, lo que le dará tiempos de carga de página más rápidos.

En el caso de una sola variable, en realidad no hace mucha diferencia. Pero para múltiples variables, quiere minimizar el cambio de contexto entre HTML y ASP: recibirá un golpe por cada salto de uno a otro.

Para ayudar con la legibilidad en la construcción de una declaración más larga, puede utilizar la línea Charcter VBScript continuación y pestañas en el código fuente (pero no el de salida) para representar la estructura sin golpear a su rendimiento:

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

No es tan legible como la versión HTML, pero si se dejan caer muchas variables en la salida (es decir, una gran cantidad de cambios de contexto entre HTML y ASP), verá un mejor rendimiento.

Ya sea que las ganancias de rendimiento valen la pena o que sea mejor escalar el hardware es una pregunta aparte, y, por supuesto, no siempre es una opción.

Actualización: ver puntas 14 y 15 en este artículo de MSDN por Len cardenal para información sobre cómo mejorar el rendimiento con Response.Buffer y evitando el cambio de contexto: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

Answer 11

Intento usar el paradigma MVC cuando hago ASP/PHP. Hace las cosas más fáciles de mantener, rediseñar, ampliar. En ese sentido, tiendo a tener una página que representa el modelo. Es principalmente VB/PHP y establece vars para su uso posterior en la vista. También genera trozos de HTML cuando se repite para su posterior inclusión en la vista. Entonces tengo una página que representa la vista. Eso es principalmente HTML salpicado con <% =%> etiquetas. El modelo es #include -d en la vista y listo. La lógica del controlador generalmente se realiza en JavaScript en una tercera página o en el lado del servidor.

Answer 12

Muchas de las respuestas aquí indican que los dos enfoques producen el mismo resultado y que la elección es de estilo de codificación y rendimiento. Parece que se cree que el contenido estático fuera de <%%> se convierte en una sola Response.Write.

Sin embargo, sería más exacto decir que el código fuera <%%> se envía con BinaryWrite.

Response.Write toma una cadena Unicode y la codifica en la página Response.CodePage antes de colocarla en el búfer. Ninguna codificación de este tipo tiene lugar para el contenido estático en un archivo ASP. Los caracteres que se encuentran fuera de <%%> se vuelcan en bytes literales por bytes en el búfer.

Por lo tanto, donde Response.CodePage es diferente de la página de códigos que se utilizó para guardar el archivo ASP, los resultados de los dos enfoques pueden diferir.

Por ejemplo Digamos que tengo guardado en una página estándar 1252 código de este contenido: -

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

El primer párrafo es confuso, ya que el £ no se enviará utilizando codificación UTF-8, el segundo es bien porque la cadena Unicode proporcionada está codificada en UTF-8.

Por lo tanto, desde un punto de vista de rendimiento es preferible utilizar contenido estático ya que no necesita codificación, pero se necesita cuidado si la página de códigos guardados difiere de la página de códigos de salida. Por esta razón, prefiero guardar como UTF-8, incluir <% @ codepage = 65001 y establecer Response.Charset = "UTF-8".

Answer 13

Estoy de acuerdo con Jason, más ahora que .NET está ofreciendo un marco MVC como alternativa a ese horrible formulario web/Postback/ViewState .NET comenzó con.

Tal vez sea porque era el clásico ASP/HTML/JavaScript de la vieja escuela y no un programador de aplicaciones de escritorio VB que me hizo simplemente no entender "The Way of the Web Form?" pero estoy tan contento de que parezca que estamos dando un rodeo completo y volvamos a una metodología como Jason se refiere a.

Con esto en mente, siempre elegiría una página incluida que contenga su modelo/lógica y <% =%> tokens dentro de su plantilla, efectivamente, la "vista" HTML. Su HTML será más "legible" y su lógica se separará tanto como el ASP clásico; estás matando un par de pájaros con esa piedra.

Answer 14

Mi ASP clásico está oxidado, pero:

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

esto se ejecuta como está. Esto, sin embargo:

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

resultados en:

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

Donde \ r \ n es un vbCrLf

Así que, técnicamente, el segundo es más rápido. SIN EMBARGO, la diferencia se mediría en milisegundos, por lo que no me preocuparía. Me preocuparía más que el primero sea prácticamente imposible de mantener (especialmente por un desarrollador de UI HTML), mientras que el segundo es trivial de mantener.

apoyos a @Euro Micelli - el mantenimiento es la clave (que es también la razón por la cual idiomas como Ruby, Python y en el pasado (aún ...) C# y Java patearon C, C++ y Assembly- humans podría mantener el código, que es mucho más importante que el afeitado algunos ms de una carga de la página.

Por supuesto, C/C++, etc tienen su lugar .... pero esto no lo es. :)

Answer 15

Si debe escribir y mantener una aplicación ASP clásica, debe consultar el motor de plantillas gratuito KudzuASP.

Es capaz de separar el código y HTML en un 100% y permite el contenido condicional, la sustitución de variables, el control de nivel de plantilla de la página asp original. If-Then-Else, Try-Catch-Finally, Switch-Case y otras etiquetas estructurales están disponibles, así como etiquetas personalizadas basadas en la página asp o en librerías dinámicamente cargables (archivos de código asp). Las etiquetas estructurales pueden integrarse dentro de otras estructuras etiquetas a cualquier nivel deseado.

Las etiquetas personalizadas y las bibliotecas de etiquetas son fáciles de escribir y se pueden incluir en el nivel de código de la página asp o mediante el uso de una etiqueta de inclusión en el nivel de la plantilla.

Las páginas maestras se pueden escribir invocando un motor de plantillas en el nivel de página maestra y aprovechando un segundo motor de plantillas hijo para cualquier contenido interno.

En KudzuASP la página ASP contiene sólo el código, crea el motor de plantillas, establece las condiciones iniciales e invoca la plantilla. La plantilla contiene diseño HTML. Una vez que la página ASP invoca la plantilla entonces se convierte en un recurso orientado a eventos totalmente impulsado por la evaluación de la plantilla y la estructura que contiene.