Ответ.Напишите против <%= %>

StackOverflow https://stackoverflow.com/questions/151448

  •  02-07-2019
  •  | 
  •  

Вопрос

Принимая во внимание, что это для классический жерех

Что лучше, весь HTML содержится в ответе.Пишите инструкции или вставляйте переменные в 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

против

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

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

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

Это было полезно?

Решение

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

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

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

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

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

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

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

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

Другие советы

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

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

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.Буферизация и предотвращение переключения контекста: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

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

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

Ответ.Write принимает строку в Юникоде и кодирует ее в текущий ответ.Кодовая страница перед помещением ее в буфер.Такое кодирование статического содержимого в ASP-файле не выполняется.Персонажи снаружи <% %> сбрасываются дословно, байт за байтом, в буфер.

Следовательно, если ответ.Кодовая страница отличается от кодовой страницы, которая использовалась для сохранения файла 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 и задайте ответ.Кодировка = "UTF-8".

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

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

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

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

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

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

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

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

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

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

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

Где - это vbCrLf

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

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

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

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

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

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

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

Ответ.Напишите "foo". лучше, когда вам нужно что-то сделать Встроенный HTML с большим количеством кода.

Технически, это одно и то же.

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top