Respuesta.Escribir vs <%= %>

Desde un punto de vista de preferencia personal, prefiero el método ya que siento que proporciona una mejor separación entre el contenido variable y el contenido estático.

Dejando de lado los problemas de readibilidad/mantenibilidad del código que otros han abordado, su pregunta fue específicamente sobre el rendimiento cuando tiene múltiples variables para insertar, así que asumo que va a repetir algo como su fragmento de código varias veces. En ese caso, usted debe obtener el mejor rendimiento mediante el uso de una sola respuesta.Escribe sin concatenar todas las nuevas líneas:

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

El navegador no necesita las nuevas líneas o las pestañas o cualquier otro bonito formateo para analizar el HTML. Si usted va para el funcionamiento, usted puede quitar todos estos. También hará que su salida HTML sea más pequeña, lo que le dará tiempos de carga de página más rápidos.

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

Para ayudar con la readibilidad al construir una declaración más larga, puede use el charcter y las pestañas de continuación de línea VBScript en su código fuente (pero no en la salida) para representar la estructura sin afectar 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 está soltando muchas variables en la salida (es decir, una gran cantidad de cambio de contexto entre HTML y ASP), verá un mejor rendimiento.

Si las ganancias de rendimiento valen la pena o si sería mejor escalar su hardware es una pregunta separada, y, por supuesto, no siempre es una opción.

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

Muchas de las respuestas aquí indican que los dos enfoques producen la misma salida y que la elección es una de estilo de codificación y rendimiento. Parece que se cree que el contenido estático fuera de se convierte en una única Respuesta.Escribir.

Sin embargo, sería más preciso decir que el código fuera de se envía con escritura BinaryWrite.

Respuesta.Write toma una cadena Unicode y la codifica en la respuesta actual.CodePage antes de colocarlo en el búfer. No hay tal codificación se lleva a cabo para el contenido estático en un archivo ASP. Los caracteres fuera de se vierten literalmente byte por byte en el búfer.

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

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

<%
     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 la codificación UTF-8, el segundo está bien porque la cadena Unicode suministrada está codificada en UTF-8.

Por lo tanto, desde un punto de vista de rendimiento, es preferible usar contenido estático, ya que no necesita codificación, pero se necesita cuidado si la página de códigos guardada difiere de la página de códigos de salida. Por esta razón prefiero guardar como UTF-8, incluir

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

1. El HTML está expuesto al IDE que puede ser procesada dándote información sobre herramientas, cierre de etiquetas, etc.
2. Mantener la sangría en el HTML de salida es más fácil que puede ser muy útil con el diseño de reelaboración.
3. Nuevas líneas sin añadir vbCrLf en todo y de nuevo para revisar la fuente de salida.

El formato de respuesta renderizará HTML de la siguiente manera:

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

Como resultado, no solo los medios para producir su código serán ilegibles, sino que el resultado también se tabulará de manera inapropiada. Stick con la otra opción.

Prefiero <%= %> únicamente porque facilita el desarrollo de Javascript. Puede escribir código que haga referencia a sus controles como este

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

Entonces puedo usar ese control de cualquier manera que me gustaría en mi código javascript sin tener que preocuparme por los IDS codificados.

Respuesta.Escribir puede romper algunos ASP.NET Código AJAX en algunas ocasiones, así que trato de evitarlo a menos que lo use para representar cosas específicas en controles personalizados.

Trato de 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 hace un bucle para su posterior inclusión en la vista. Luego tengo una página que representa la vista. Eso es principalmente HTML salpicado de etiquetas. El modelo es # include-d en la vista y listo. La lógica del controlador es normalmente se realiza en JavaScript en una tercera página o en el lado del servidor.

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 tal cual. 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, así que no me preocuparía por ello. Yo estaría más preocupado de que la parte superior es prácticamente inalcanzable (esp por un desarrollador de interfaz de usuario HTML), donde como el segundo es trivial de mantener.

Props a @Euro Micelli - el mantenimiento es la clave (que es también por qué lenguajes como Ruby, Python, y en el pasado (tho todavía....) C# y Java patearon a tope sobre C, C++ y Assembly - los humanos podrían mantener el código, que es mucho más importante que afeitar unos pocos ms de una carga de página.

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

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

No hay mejora de rendimiento cambiando a Respuesta.Escribir, y puede ser más rápido de leer y mantener utilizando la notación de acceso directo.

Debe enmarcar estas preguntas en términos de reutilización y mantenimiento del código (también conocido como legibilidad). Realmente no hay ganancia de rendimiento de cualquier manera.

es útil cuando se genera HTML a partir de una expresión corta en línea con algún HTML.

Respuesta.Escribir " foo " es mejor cuando necesitas hacer algo de HTML en línea con mucho código.

Técnicamente, son lo mismo.

Hablando de tu ejemplo, sin embargo, la Respuesta.Write code hace mucha concatenación de cadenas con&, que es muy lenta en VBScript. También, como [17]} Russell Myers dijo , es no tabulado de la misma manera que su otro código, que podría ser involuntario.

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

Tal vez es porque yo era clásico de la vieja escuela ASP/HTML/JavaScript y no un programador de aplicaciones de escritorio VB que me hizo simplemente no grokk "El Camino de la Forma Web?"pero estoy muy contento de que parezcamos estar cerrando el círculo y volviendo a una metodología como a la que se refiere Jason .

Con eso en mente, me gustaría siempre elija una página incluida que contenga su modelo/lógica y tokens dentro de su, efectivamente plantilla HTML " vista."Tu HTML será más "legible" y tu lógica se separará tanto como lo permita el ASP clásico; estás matando a un par de pájaros con esa piedra.

Si se le requiere escribir y mantener una aplicación ASP Clásica, debe revisar el motor de plantillas KudzuASP gratuito.

Es capaz de 100% de separación de código y HTML y permite contenido condicional, sustitución de variables, 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 bibliotecas cargables dinámicamente (archivos de código asp) Estructural las etiquetas se pueden incrustar dentro de otras etiquetas estructurales 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 include en el nivel de plantilla.

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

En KudzuASP su página asp contiene solo código, crea el motor de plantillas, configura condiciones iniciales e invoca la plantilla. La plantilla contiene diseño HTML. Una vez que la página asp invoca la plantilla, se convierte en un recurso impulsado por eventos completamente impulsado por la evaluación de la plantilla y la estructura que contiene.