これはクラシックASP用であることを念頭に置いてください
どちらが良いか、Response.Writeステートメントに含まれるすべての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
VS
<table>
<tr>
<td class="someClass"><%= someVariable %></td>
</tr>
</table>
私は主に、挿入する変数が複数ある場合にサーバーへの影響が最も少ないパフォーマンスの観点から質問しています。
技術的な違いがない場合、どちらか一方の主張は何ですか？
まず、あなたが見なければならない最も重要な要素は、メンテナンスの容易さです. 面倒な Web サイトを解読して維持するために浪費するお金と時間を使って、サーバー ファームを購入することができます。
いずれにせよ、それは問題ではありません。結局のところ、ASP はスクリプトを実行するだけです。ASP パーサーがページを受け取り、<%= expression %>スクリプトの直接呼び出しに変換し、HTML のすべての連続ブロックが への 1 つの巨大な呼び出しになりResponse.Writeます。結果のスクリプトはキャッシュされ、ディスク上のページが変更されない限り再利用されます。これにより、キャッシュされたスクリプトが再計算されます。
現在、 を使いすぎると<%= %>、「スパゲッティ コード」の現代版、恐ろしい「タグ スープ」につながります。ロジックの表と裏を作ることはできません。一方、Response.Write を使いすぎると、ページがレンダリングされるまでまったく表示されなくなります。適切な場合に使用<%= %>して、両方の利点を最大限に活用してください。
私の最初のルールは、「可変テキスト」と「静的テキスト」の比率に注意を払うことです。
置換する可変テキストのある場所が数か所しかない場合、<%= %>構文は非常にコンパクトで読みやすいです。ただし、<%= %>蓄積が始まると、それらは HTML をますます覆い隠し、同時に HTML はロジックをますます覆い隠します。原則として、ループについて取り始めたら、停止して Response.Write` に切り替える必要があります。
厳格なルールは他にあまりありません。特定のページ (またはページのセクション) について、ロジックと HTML のどちらがより重要であるか、当然理解するのが難しいか、壊れやすいかを判断する必要があります。通常はどちらか一方です（両方のケースを何百回も見てきました）
ロジックがより重要な場合は、より重視する必要がありますResponse.Write。ロジックを際立たせます。HTML がより重要な場合は<%= %>、ページ構造がより見やすくなる を支持してください。
場合によっては、両方のバージョンを作成して並べて比較し、どちらがより読みやすいかを判断する必要がありました。これは最後の手段ですが、コードが新鮮なうちに実行してください。そうすれば、3 か月後に変更が必要になったときに満足できるでしょう。
個人的な好みの観点から、静的コンテンツからのより良い分離変数コンテンツを提供すると思うので、私は<％=％>メソッドを好みます。
ここでの回答の多くは、2 つのアプローチが同じ出力を生成し、選択はコーディング スタイルとパフォーマンスのいずれかであることを示しています。<% %> の外側の静的コンテンツは単一の Response.Write になると考えられているようです。
ただし、<% %> の外側のコードは BinaryWrite で送信されると言う方が正確です。
Response.Write は Unicode 文字列を受け取り、それを現在の Response.CodePage にエンコードしてからバッファに配置します。ASP ファイル内の静的コンテンツに対しては、このようなエンコードは行われません。<% %> の外側の文字は、1 バイトずつバッファーにダンプされます。
したがって、Response.CodePage が ASP ファイルの保存に使用された CodePage と異なる場合、2 つのアプローチの結果が異なる場合があります。
たとえば、このコンテンツを標準の 1252 コード ページで保存したとします。
<%
Response.CodePage = 65001
Response.CharSet = "UTF-8"
%>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>
最初の段落は文字化けしています。£ は UTF-8 エンコードを使用して送信されないためです。2 番目の段落は、提供された Unicode 文字列が UTF-8 にエンコードされているため問題ありません。
したがって、エンコーディングを必要としないため、パフォーマンスの観点から静的コンテンツを使用することが望ましいですが、保存されたコードページが出力コードページと異なる場合は注意が必要です。このため、私は UTF-8 として保存し、<%@ codepage=65001 を含め、Response.Charset = "UTF-8" を設定することを好みます。
他の人が対処したコードの読みやすさ/保守性の問題は別として、あなたの質問は、挿入する変数が複数ある場合のパフォーマンスに関するものでした-したがって、コードフラグメントのようなものを複数回繰り返すと思います。その場合、すべての改行を連結せずに単一の 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。
いくつかの理由から、私はほとんどの状況で <%= %> メソッドを好みます。
私が好む<%= %>のは、Javascript の開発が容易になるという理由だけです。このようにコントロールを参照するコードを書くことができます
var myControl = document.getElementById('<%= myControl.ClientID %>');
その後、ハードコードされた ID を気にすることなく、JavaScript コードで好きなようにそのコントロールを使用できます。
Response.Write は、場合によっては ASP.NET AJAX コードを壊す可能性があるため、カスタム コントロールで特定のものをレンダリングするために使用しない限り、回避しようとしています。
応答形式は、次のように HTML をレンダリングします。
<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>
その結果、コードを生成する手段が読めなくなるだけでなく、結果も不適切にタブ化されます。他のオプションに固執します。
私の古典的な 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 開発者による) 保守がほとんど不可能であることがより懸念されますが、2 番目のものは保守が簡単です。
@Euro Micelliへの小道具 - メンテナンスが鍵です（これが、Ruby、Python、そして過去に（それでも....）C＃やJavaなどの言語がC、C ++、Assemblyよりもお尻を蹴った理由でもあります-人間はコードを維持できましたこれは、ページの読み込みを数ミリ秒短縮するよりもはるかに重要です。
もちろん、C/C++ などにはそれぞれの場所があります....しかし、これはそうではありません。:)
I try to use the MVC paradigm when doing ASP/PHP. It makes things easiest to maintain, re-architect, expand upon. In that regard, I tend to have a page that represents the model. It's mostly VB/PHP and sets vars for later use in the view. It also generates hunks of HTML when looping for later inclusion in the view. Then I have a page that represents the view. That's mostly HTML peppered with <%= %> tags. The model is #include -d in the view and away you go. Controller logic is typically done in JavaScript in a third page or server-side.
<%= %>残りはに拡張されるResponse.Write()ので、最終的には同じになります。
Response.Write に切り替えてもパフォーマンスが向上することはなく、ショートカット表記を使用して読み取りと保守を高速化できます。
この質問は、コードの再利用とコードの保守性 (別名、読みやすさ) の観点から組み立てる必要があります。どちらの方法でも、実際にはパフォーマンスの向上はありません。
<%=Bazify()%>は、いくつかの HTML インラインで短い式から HTML を生成する場合に便利です。
Response.Write "foo"は、多くのコードでインラインで HTMLを実行する必要がある場合に適しています。
技術的には、それらは同じです。
ただし、あなたの例について言えば、 Response.Write コードは & を使用して多くの文字列連結を行いますが、これはVBScript では非常に低速です。また、Russell Myers が言ったように、他のコードと同じようにタブ化されていないため、意図的ではない可能性があります。
私はJasonに同意します。さらに、.NET が MVC フレームワークを、.NET が最初に使用したひどい Web フォーム/ポストバック/ViewState の代わりとして提供していることに同意します。
多分それは、私が昔ながらの古典的な ASP/HTML/JavaScript であり、VB デスクトップ アプリケーション プログラマーではなく、「Web フォームのやり方」を理解できなかったからかもしれません。しかし、ジェイソンが言及したような方法論に完全に戻り、戻ってきているように見えることをとてもうれしく思います.
そのことを念頭に置いて、私は常に、モデル/ロジックと <%= %> トークンを効果的にテンプレート化した HTML "ビュー" 内に含むページを選択します。HTML はより「読みやすく」なり、従来の ASP と同じようにロジックが分離されます。あなたはその石で数羽の鳥を殺しています。