3

私が通常採用しているアプローチについて、他の開発者から意見を聞くことに興味があります。私はWebアプリケーション、asp.net 2.0、c＃を持っています。

ドロップダウン、テーブル、入力コントロールなどを書き出すために私が通常行うことは、StringBuilderを使用して、sb.Append（"のようなものを書き出す背後にあるコードにあります。

私は通常、コードビハインドでhtmlを書き出すので、多くの.netコントロールを使用していることに気づきません。jQueryを使用したりJavaScriptを呼び出したりする場合は、その関数呼び出しをsb.Append（ "td ... onblur ='fnCallJS（）'のようなsb.Appendタグに入れるだけです。

私はこのアプローチにかなり慣れてきました。データアクセスには、EntitySpacesを使用します。

この種のアプローチがひどく間違っているかどうか、私はちょっと興味があります。コンテキスト、良い、3.0を学ぶ時間などによっては大丈夫です。私は学習に興味があり、いくつかの入力を探していました。

編集

ここでコメントを読んだ後、MVCを確認する必要があるようです。私はまだそれをしていません。そうすることの唯一の躊躇は、既存のプロジェクトがまさにそれであり、存在しているということです。私が説明した方法ですでに多くのコードが実行されており、それを変更することに何が関係するのか、そうすることの利点、そしてそれが何を必要とするのかを学ぶだけでは想像できません。

私がコメントから取り除いているもう1つのことは、背後にある私のコードには実際にはsb.Appendコードの多くが含まれていてはならないのに対し、今では多くの関数でコードが満たされているということです。私にとっては面倒ではありませんが、それは各関数が何をするのかを知っていて、それを見て、x、y、zを書き出すことができるからです。

.aspx部分にdivを設定し、コードビハインドのStringBuilderを使用してその.innerHtmlを構築することは珍しくありません。

コメントありがとうございます。私はそれらを読んでいるときに考えています。

4

8 に答える 8

2

私は通常、コードビハインドでhtmlを書き出します。

その部分は少し奇妙で、私がWebフォームに推奨するものではありません。それを実行したい場合は、代わりにasp.netmvcプロジェクトを検討してください。

Webフォームでは、HTMLの要点を、コードではなくマークアップと一緒に使用する必要があります。2つは別々のままにする必要があります。また、ページ全体を網羅する巨大な文字列ビルダーは必要ありません。これにより、ページをビルド時に応答ストリームに書き込むのではなく、ページ全体を2回（stringbuilderバイト用に1回、最後にビルドされた文字列用に1回）メモリに保持する必要があります。つまり、リクエストごとのメモリが増えるため、スケーラビリティが大幅に低下する可能性があります。

そのために、stringbuilderコードの個別の部分を、aspxマークアップで使用できるカスタム/ユーザーコントロールに抽象化します。これらのコントロールは、stringbuilderを使用して出力を作成できます。つまり、一度に1つのコントロールをレンダリングするのに十分なHTMLマークアップをメモリに保持するだけで済みます。また、ページ間またはサイト間で共通のマークアップをより簡単に再利用できます。

于 2010-03-25T03:26:14.523 に答える
1

手足に出て、「クラシック」ASP（vbScript）またはPHPのバックグラウンドから来たのではないかと思います。

私のバックグラウンドは「ClassicASP」であり、Webforms Modelでの最初の試みは、あなたとほとんど同じでした。一度それらを使用して理解し始めたら、振り返ることはありませんでした。ページのライフサイクルがさまざまなWebFormコントロールとどのように相互作用するかを理解するには、明確な学習曲線があります。

ASP.net WebFormsとMCVのさまざまなスレッドを調べて、プロジェクトに最適なスレッドを確認してください。MVCは魔法の治療法ではありませんが、「クラシックASP」またはPHPのバックグラウンドを使用している場合は、多くの点でより馴染みがあるかもしれません。

実用的な観点から、WebFormsに固執していると仮定すると、他の開発者がプロ​​ジェクトに関与する可能性がある場合は、可能な限り多くの組み込みコントロールを使用することを目指します。 。当然のことながら、コントロールを使用すればするほど、コントロールでできることとできないことを理解できるようになり、やがて、ギャップを埋めるために独自のコントロールを作成したり、既存のサードパーティのコントロールを見つけたりするようになります。

于 2010-03-25T04:57:54.833 に答える
1

コードでHTMLを生成する必要がある場合もありますが、一般的には、HTMLを元の場所に残しておき、それをコードから分離します。VSIDEはかなり優れたHTMLエディターです。これを使って。

于 2010-03-25T03:27:34.540 に答える
0

かなり厄介になる可能性があるという大きな問題があります...すべての"をエスケープするか、キャリッジリターンをいじる必要があります。確かにそれを回避してプログラムできますが、コードをコピーして貼り付けたい場合はどうでしょうか？悪夢のように聞こえますそれが価値があるよりもはるかに多くの仕事。

于 2010-03-25T03:26:55.877 に答える
0

カスタムコントロールを作成し、HtmlTextWriterを使用してマークアップを作成する必要があるようです。

または、おそらくより適切なのは、aspxページにマークアップを配置し、コードビハインドに他の何かを配置するユーザーコントロールです。

于 2010-03-25T03:31:21.107 に答える
0

このアプローチを使用している場合は、開発作業をASP.NetMVCに移行する必要があります。ASP.NetはWebコントロールを使用してHTML、CSS、JavaScriptなどを積極的に抽象化しようとしますが、ASP.Net MVCは、マークアップ自体を直接制御するというパラダイムに基づいて構築されています（ただし、これはおそらく、 2つ-長期的にASP.Netを使い続ける場合でも、少なくとも代替案を知るために必ず読んでおく必要があります）。

それ以外の場合は、適切に実行すれば（フレームワークと完全に戦うことになりますが）、代わりにStringWriterを使用することをお勧めします。内部でStringBuilderを使用するため、パフォーマンス特性は2つで同じですが、セマンティクスは.Netフレームワークの残りの部分（たとえば、書き込みと追加）とより一貫性があります。

于 2010-03-25T03:31:32.683 に答える
0

このアプローチは、Web フォームが達成しようとしていた目的 (マークアップとコードの分離) を無効にしていると思います。

于 2010-03-25T03:40:00.270 に答える