Response.Write vs <% =%>

Question

Имея в виду, это для классического жереха

Что лучше, весь HTML-код, содержащийся в Response.Write Statements или вставке переменных в HTML через <% =%>.
Например,

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>

Я в основном спрашиваю с точки зрения производительности, в какой мере сервер будет иметь наименьшее влияние при добавлении нескольких переменных?

Если нет технических отличий, каковы аргументы одного над другим?

Answer 1

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

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

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

Мое первое правило - обращать внимание на соотношение «переменного текста» и «статического текста».

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

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

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

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

Answer 2

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

Answer 3

Многие ответы здесь указывают на то, что два подхода дают один и тот же результат и что выбор зависит от стиля и производительности кодирования. Кажется, считается, что статическое содержимое за пределами <%%> становится единым 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, второй подойдет, потому что предоставленная строка Unicode кодируется в UTF-8.

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

Answer 4

Оставляя в стороне вопросы читабельности / удобства сопровождения кода, которые были рассмотрены другими, ваш вопрос был конкретно о производительности, когда у вас есть несколько переменных для вставки - поэтому я предполагаю, что вы будете повторять что-то вроде фрагмента кода несколько раз. В этом случае вы должны получить наилучшую производительность, используя один 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 Лена Кардинала для получения информации об улучшении производительности с Response.Buffer и избегании переключения контекста: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

Answer 5

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

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

Answer 6

Мой классический 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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

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

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