Response.Write vs＆lt;％=％＆gt;

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

  •  02-07-2019
  •  | 
  •  

質問

これは classic asp

用です。

より良いのは、Response.Writeステートメントに含まれるすべてのHTMLまたは＆lt;％=％＆gt;を介して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>

主に、挿入する複数の変数があるときにサーバーへの影響が最も少ないパフォーマンスの観点から質問していますか？

技術的な違いがない場合、一方の引数は他方の引数とは何ですか？

役に立ちましたか？

解決

まず、最も重要な要素は、メンテナンスの容易さです。乱雑なWebサイトを解読して維持することで、それ以外の場合は無駄になるお金と時間でサーバーファームを購入できます。

いずれにしても、それは問題ではありません。結局のところ、ASPはスクリプトを実行するだけです！ ASPパーサーはページを取得し、＆lt;％= expression％＆gt; を直接のスクリプト呼び出しに変換し、HTMLのすべての連続ブロックが Response.Write の1つの巨大な呼び出しになります。ディスク上でページが変更されない限り、結果のスクリプトはキャッシュされて再利用され、キャッシュされたスクリプトが再計算されます。

＆lt;％=％＆gt; の使用が多すぎると、「スパゲッティコード」の最新バージョンになります：恐ろしい「タグスープ」。ロジックの先頭や末尾を作成することはできません。一方、Response.Writeを使いすぎると、レンダリングするまでページをまったく見ることができなくなります。必要に応じて＆lt;％=％＆gt; を使用して、両方の世界を最大限に活用してください。

最初のルールは、「可変テキスト」の割合に注意を払うことです。 「静的テキスト」へ。

可変テキストを置き換える場所が数箇所しかない場合、＆lt;％=％＆gt; 構文は非常にコンパクトで読みやすいです。ただし、＆lt;％=％＆gt; の蓄積が始まると、HTMLがますます不明瞭になり、同時にHTMLがロジックを不明瞭にします。一般的なルールとして、ループの使用を開始したら、停止してResponse.Write`に切り替える必要があります。

その他の厳格なルールは多くありません。特定のページ（またはページのセクション）で、ロジックまたはHTMLのどれをより重要にするか、当然理解するのが難しいか、破りやすいのかを決定する必要があります。通常はどちらかです（両方のケースを何百回も見ました）

ロジックがより重要な場合は、 Response.Write に重点を置く必要があります。ロジックが目立つようになります。 HTMLがより重要な場合は、＆lt;％=％＆gt; を使用すると、ページ構造がより見やすくなります。

時々、両方のバージョンを作成し、それらを並べて比較して、どちらが読みやすいかを判断する必要がありました。これは最後の手段ですが、コードが心に残っている間に実行してください。3か月後に変更が必要になったら喜んでいただけます。

他のヒント

個人的な好みの観点から、私は＆lt;％=％＆gt;を好むメソッドは、静的コンテンツからのより良い分離変数コンテンツを提供すると思います。

他の人が対処したコードの読みやすさ/保守性の問題は別として、あなたの質問は、挿入する複数の変数がある場合のパフォーマンスに関するものでした。その場合、すべての改行を連結せずに、単一の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の間でコンテキストを切り替える場合）、パフォーマンスが向上します。

パフォーマンスの向上に値するかどうか、またはハードウェアをスケーリングする方が良いかどうかは別の質問です-もちろん、それは常にオプションではありません。

更新： Response.Bufferによるパフォーマンスの改善とコンテキスト切り替えの回避に関する情報については、Len CardinalによるこのMSDN記事のヒント14と15を参照してください： http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 。

>

ここでの回答の多くは、2つのアプローチが同じ出力を生成し、選択がコーディングスタイルとパフォーマンスのいずれかであることを示しています。 ＆lt;％％＆gt;以外の静的コンテンツは、単一のResponse.Writeになります。

ただし、＆lt;％％＆gt;の外側のコードを言う方が正確です。 BinaryWriteで送信されます。

Response.Writeは、Unicode文字列を取得し、現在のResponse.CodePageにエンコードしてから、バッファーに配置します。 ASPファイルの静的コンテンツに対しては、このようなエンコードは行われません。 ＆lt;％％＆gt;以外の文字バイトごとにバッファに逐語的にダンプされます。

したがって、Response.CodePageがASPファイルの保存に使用されたCodePageと異なる場合、2つのアプローチの結果は異なる場合があります。

たとえば、このコンテンツを標準の1252コードページに保存するとします：-

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

最初の段落は文字化けしています。＆＃163; UTF-8エンコードを使用して送信されません。2番目は、指定されたUnicode文字列がUTF-8にエンコードされているため問題ありません。

したがって、静的コンテンツを使用するパフォーマンスの観点からは、エンコードは必要ありませんが、保存されたコードページが出力コードページと異なる場合は注意が必要なので、望ましいです。このため、UTF-8として保存し、＆lt;％@ codepage = 65001を含め、Response.Charset =＆quot; UTF-8＆quot;を設定します。

＆lt;％=％＆gt;を好むいくつかの理由でほとんどの状況でメソッド。

  1. HTMLはIDEに公開されるため、 処理できること ツールチップ、タグのクローズなど。
  2. インデントを維持する 出力HTMLは簡単です レイアウトの修正に非常に役立ちます。
  3. vbCrLfを追加しない改行 出力ソースを確認するために何度も繰り返します。

応答形式は次のようにHTMLをレンダリングします：

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

結果として、コードを生成する手段が読めなくなるだけでなく、結果も不適切にタブ化されます。他のオプションに固執します。

＆lt;％=％＆gt; を好むのは、Javascriptの開発を簡単にするためだけです。このようにコントロールを参照するコードを書くことができます

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

その後、ハードコードされたIDを気にすることなく、javascriptコードで好きな方法でそのコントロールを使用できます。

Response.Writeは、場合によってはASP.NET AJAXコードを壊す可能性があるため、カスタムコントロールで特定のものをレンダリングするために使用しない限り、回避しようとしています。

ASP / PHPを実行するときにMVCパラダイムを使用しようとしています。物事の維持、再設計、拡張が最も簡単になります。その点で、私はモデルを表すページを持つ傾向があります。ほとんどはVB / PHPで、ビューで後で使用するために変数を設定します。また、ビューに後で含めるためにループするときにHTMLの塊を生成します。次に、ビューを表すページがあります。ほとんどはHTMLで、＆lt;％=％＆gt;タグ。モデルはビューに#include -dされており、すぐに使用できます。通常、コントローラーロジックはJavaScriptで3番目のページまたはサーバー側で実行されます。

私の古典的な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の場合

技術的には、2番目の方が高速です。ただし、差は1ミリ秒単位で測定されるので、心配する必要はありません。一番上のものはほとんど維持できず（HTML-UI開発者による）、もう1つは維持するのが簡単なことを心配します。

@Euro Micelliの小道具-メンテナンスが重要です（これが、Ruby、Python、および過去（tho still ....）のような言語でもある理由です）コードを維持します。これは、ページの読み込みを数ミリ秒短縮するよりもはるかに重要です。

もちろん、C / C ++などにもその場所があります。...しかし、そうではありません。 ：）

＆lt;％=％＆gt; と残りは Response.Write（）に展開されるため、最終的には同じになります。

Response.Writeへの切り替えによるパフォーマンスの改善はありません。また、ショートカット表記を使用して、読み取りと保守を高速化できます。

コードの再利用とコードの保守性（読みやすさ）の観点から、この質問を構成する必要があります。どちらの方法でもパフォーマンスはまったく向上しません。

＆lt;％= Bazify（）％＆gt; は、 HTMLとインラインで短い式からHTMLを生成する場合に便利です。

Response.Write＆quot; foo＆quot; は、多くのコードで HTMLをインラインで実行する必要がある場合に優れています。

技術的には、それらは同じです。

ただし、例について言えば、Response.Writeコードは＆amp;と多くの文字列の連結を行います。これは VBScriptで非常に遅い。また、ラッセルマイヤーズが言ったように、他のコードと同じようにタブ付けされていません。 。

Jason に同意します。今では.NETがその代わりにMVCフレームワークを提供していますひどいWebフォーム/ポストバック/ ViewState .NETの開始時。

たぶん、私は昔の古典的なASP / HTML / JavaScriptであり、VBデスクトップアプリケーションプログラマーではなかったために、「Webフォームの道？」しかし、 Jason が言及しているような方法論に戻ってきているように思えるのでとても嬉しいです。

そのことを念頭に置いて、モデル/ロジックと＆lt;％=％＆gt;を含むインクルードページを常に選択します。効果的にテンプレートHTML内のトークン＆quot; view。＆quot; HTMLがより「読みやすく」なります。そして、古典的なASPが許す限りロジックを分離しました。その石で数羽の鳥を殺しています。

クラシックASPアプリケーションの作成と保守が必要な場合は、無料のKudzuASPテンプレートエンジンをチェックアウトする必要があります。

100％コードとHTML分離が可能で、条件付きコンテンツ、変数置換、元のASPページのテンプレートレベル制御が可能です。 If-Then-Else、Try-Catch-Finally、Switch-Case、およびその他の構造タグと、aspページまたは動的にロード可能なライブラリ（aspコードファイル）に基づくカスタムタグを使用できます。構造タグを他の構造タグに埋め込むことができます。任意のレベルにタグ付けします。

カスタムタグとタグライブラリは簡単に記述でき、aspページのコードレベルで含めるか、テンプレートレベルでincludeタグを使用して含めることができます。

マスターページレベルでテンプレートエンジンを呼び出し、内部コンテンツに2番目の子テンプレートエンジンを利用することで、マスターページを作成できます。

KudzuASPでは、aspページにコードのみが含まれ、テンプレートエンジンが作成され、初期条件が設定され、テンプレートが呼び出されます。テンプレートにはHTMLレイアウトが含まれています。 aspページがテンプレートを呼び出すと、テンプレートとそれに含まれる構造の評価によって完全に駆動されるイベント駆動型リソースになります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top