Response.Write vs <% =%>

Ответ 1

Во-первых, самым важным фактором, на который вы должны обратить внимание, является простота обслуживания. Вы могли бы купить серверную ферму с деньгами и временем, в которые вы в противном случае могли бы тратить время, чтобы расшифровать грязный веб-сайт, чтобы поддерживать его.

В любом случае это не имеет значения. В конце концов, все ASP просто выполняет script! Парсер ASP принимает страницу и преобразует <%= expression %> в прямые вызовы script, и каждый непрерывный блок HTML становится одним гигантским вызовом Response.Write. Результирующий script кэшируется и повторно используется, если страница не изменяется на диске, что приводит к пересчету кэшированного script.

Теперь слишком много использования <%= %> приводит к современной версии "кода спагетти": страшный "суп-тег". Вы не сможете сделать головы или хвосты логики. С другой стороны, слишком много использования Response.Write означает, что вы никогда не сможете увидеть страницу вообще, пока она не отобразится. Используйте <%= %>, когда это необходимо, чтобы получить лучшее из обоих миров.

Мое первое правило - обратить внимание на долю "переменного текста" на "статический текст".

Если у вас есть только несколько мест с переменным текстом для замены, синтаксис <%= %> очень компактный и читаемый. Однако, когда <%= %> начинают накапливаться, они все больше скрывают HTML и в то же время HTML все больше скрывает вашу логику. Как правило, после того, как вы начинаете принимать циклы, вам нужно остановиться и переключиться на Response.Write`.

Существует не так много других жестких и быстрых правил. Вам нужно решить, какая именно страница (или раздел страницы) важнее или, естественно, сложнее понять или просто сломать: ваша логика или ваш HTML-код? Обычно это один или другой (я видел сотни случаев обоих)

Если логика более важна, вы должны больше потянуться к Response.Write; это заставит логику выделяться. Если HTML более критичен, пользуйтесь <%= %>, что сделает структуру страницы более заметной.

Иногда мне приходилось писать обе версии и сравнивать их бок о бок, чтобы решить, какой из них более читабельен; это последнее средство, но сделайте это, в то время как код свежий в вашем уме, и вы будете рады через три месяца, когда вам придется вносить изменения.

Ответ 2

С точки зрения личных предпочтений я предпочитаю метод <% =% > , поскольку я чувствую, что он обеспечивает лучшее содержимое переменной из статического содержимого.

Ответ 3

Оставив в стороне проблемы чтения/сопровождения кода, которые другие рассмотрели, ваш вопрос был конкретно о производительности, когда у вас есть несколько переменных для вставки - поэтому я предполагаю, что вы будете повторяться несколько раз, как ваш фрагмент кода. В этом случае вы должны получить максимальную производительность, используя один Response.Write без конкатенации всех новых строк:

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

Браузеру не нужны символы новой строки или вкладки или любое другое красивое форматирование для анализа HTML. Если вы собираетесь работать, вы можете удалить все из них. Вы также уменьшите свой HTML-выход, что даст вам более быстрое время загрузки страницы.

В случае одной переменной это действительно не имеет большого значения. Но для нескольких переменных вы хотите свести к минимуму переключение контекста между HTML и ASP - вы получите хитом за каждый переход от одного к другому.

Чтобы облегчить чтение при построении более длинного оператора, вы можете использовать символ продолжения строки VBScript и вкладки в исходном коде (но не на выходе), чтобы представить структуру без ущерба для вашей производительности:

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

Это не так читаемо, как версия HTML, но если вы выгружаете большое количество переменных в результат (т.е. много переключение контекста между HTML и ASP), вы увидите лучшую производительность.

Независимо от того, заслуживают ли выгоды от производительности или будут ли вы лучше масштабировать свое оборудование, это отдельный вопрос - и, конечно же, это не всегда вариант.

Обновление: см. советы 14 и 15 в этой статье MSDN от Len Cardinal для получения информации об улучшении производительности с помощью Response.Buffer и избежании переключения контекста: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

Ответ 4

Многие из ответов здесь указывают на то, что оба подхода дают один и тот же результат и что выбор является одним из стиля и производительности кодирования. Кажется, что он полагает, что статическое содержимое вне <%% > становится единственным Response.Write.

Однако было бы более точным сказать, что код вне <%% > отправляется с BinaryWrite.

Response.Write берет строку Unicode и кодирует ее до текущей Response.CodePage, прежде чем помещать ее в буфер. Такая кодировка не выполняется для статического содержимого в файле ASP. Символы вне <%% > выгружают дословный байт для байта в буфер.

Следовательно, где Response.CodePage отличается от CodePage, который использовался для сохранения ASP файла, результаты двух подходов могут отличаться.

Например, скажем, у меня есть этот контент, сохраненный на стандартной кодовой странице 1252: -

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

Первый абзац искажен, так как £ не будет отправлен с использованием кодировки UTF-8, второй - в порядке, потому что поставляемая строка Юникода закодирована в UTF-8.

Следовательно, с точки зрения производительности, используя статический контент, предпочтительнее, поскольку он не нуждается в кодировании, но требуется осторожность, если сохраненная кодовая страница отличается от выходной кодовой страницы. По этой причине я предпочитаю сохранять как UTF-8, включать <% @codepage = 65001 и устанавливать Response.Charset = "UTF-8".

Ответ 5

Я предпочитаю метод <% =% > в большинстве ситуаций по нескольким причинам.

• HTML подвергается воздействию IDE, поэтому что его можно обработать, давая вам всплывающие подсказки, закрытие тегов и т.д.
• Сохранение отступов в вывода HTML проще, что может быть очень полезно при переработке макета.
• Новые строки без добавления vbCrLf на все и снова для просмотра источника вывода.

Ответ 6

Формат ответа отобразит HTML следующим образом:

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

В результате не только средства для создания вашего кода будут нечитабельными, но и результат будет неправильно введен неправильно. Используйте другой вариант.

Ответ 7

Я предпочитаю <%= %> исключительно потому, что он упрощает Javascript. Вы можете написать код, который ссылается на ваши элементы управления, такие как

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

Затем я могу использовать этот элемент управления любым способом, который мне нужен в моем коде javascript, не беспокоясь о жестких кодированных идентификаторах.

Response.Write может разорвать некоторый код ASP.NET AJAX в некоторых случаях, поэтому я стараюсь избегать его, если не использовать его для рендеринга определенных вещей в пользовательских элементах управления.

Ответ 8

Я пытаюсь использовать парадигму MVC при выполнении ASP/PHP. Это упрощает работу, перестраивает архитектуру, расширяется. В связи с этим у меня есть страница, представляющая модель. Это в основном VB/PHP и устанавливает vars для последующего использования в представлении. Он также генерирует hunk файлы HTML при циклировании для последующего включения в представление. Затем у меня есть страница, представляющая представление. Это в основном HTML, набитый тегами <% =% > . Модель - #include -d в представлении, и вы уходите. Логика контроллера обычно выполняется в JavaScript на третьей странице или на стороне сервера.

Ответ 9

Мой классический ASP ржавый, но:

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

это выполняется как есть. Это, однако:

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

приводит к:

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

Где\r\n - это vbCrLf

Итак, технически, второй - быстрее. ОДНАКО, разница будет измеряться за один миллисекунд, поэтому я бы не стал беспокоиться об этом. Я был бы более обеспокоен тем, что верхняя часть в значительной степени недостижима (esp разработчиком HTML-UI), где второй тривиально поддерживать.

реквизит для @Euro Micelli - обслуживание - это ключ (а также такие языки, как Ruby, Python и в прошлом (еще до сих пор). С# и Java пинали ногами над C, С++ и Assembly-people могли поддерживайте код, что является более важным, чем бритье нескольких мс при загрузке страницы.

Конечно, C/С++ и т.д. имеют свое место.... но это не так.:)

Ответ 10

<%= %>, а остальные расширяются до Response.Write(), поэтому в конце концов это тоже самое.

Ответ 11

Нет улучшения производительности, переключаясь на Response.Write, и его можно быстрее читать и поддерживать с помощью нотации ярлыка.

Ответ 12

Вы должны сформулировать эти вопросы с точки зрения повторного использования кода и ремонтопригодности кода (он же читаемости). В действительности нет никакого выигрыша в производительности.

Ответ 13

<% = Bazify()% > полезен, когда вы генерируете HTML из строкового выражения с некоторым HTML.

Response.Write "foo" лучше, когда вам нужно сделать несколько HTML-строк с большим количеством кода.

Технически, они одинаковы.

Говоря о вашем примере, код Response.Write выполняет много конкатенации строк с помощью &, который очень медленный в VBScript. Кроме того, как Рассел Майерс сказал, он не внесен в закладки так же, как ваш другой код, что может быть непреднамеренным.

Ответ 14

Я согласен с Jason, тем более что .NET предлагает MVC-инфраструктуру в качестве альтернативы этой ужасной веб-форме/Postback/ViewState.NET. с.

Может быть, потому, что я был классическим ASP/HTML/JavaScript старой школы, а не программистом для настольных приложений VB, который заставил меня просто не grokk "Путь веб-формы"? но я так рад, что, кажется, идет полным кругом и возвращается к такой методологии, как Jason.

Имея это в виду, я всегда выбирал включенную страницу, содержащую ваши маркеры модели/логики и <% =% > внутри вашего, эффективного шаблона HTML "view". Ваш HTML будет более "читаемым", и ваша логика будет разделена так же, как и классический ASP; вы убиваете пару птиц этим камнем.

Ответ 15

Если вам необходимо написать и поддерживать приложение Classic ASP, вы должны проверить свободный механизм шаблонов KudzuASP.

Он способен на 100% разделение кода и HTML и позволяет использовать условный контент, замену переменных, контроль уровня шаблона исходной страницы asp. If-Then-Else, Try-Catch-finally, Switch-Case и другие структурные тэги, а также настраиваемые теги, основанные на странице asp или в динамически загружаемых библиотеках (asp файлы кода). Структурные теги могут быть встроены в другие структурные теги на любой желаемый уровень.

Пользовательские теги и библиотеки тегов легко записываются и могут быть включены на уровне кода страницы asp или с помощью тега include на уровне шаблона.

Мастер-страницы могут быть записаны путем вызова механизма шаблона на уровне главной страницы и использования второго механизма дочерних шаблонов для любого внутреннего содержимого.

В KudzuASP ваша страница asp содержит только код, создает механизм шаблона, устанавливает начальные условия и вызывает шаблон. Шаблон содержит HTML-макет. После того, как страница asp вызывает шаблон, он становится ресурсом, управляемым событиями, полностью управляемым оценкой шаблона и структуры, которую он содержит.