この質問では、OP は、新しいブログ エントリごとに 1 つずつ、.aspx ファイルの自動作成に基づいて開発しているブログ システムをベースにしたいことを暗示しています。彼の質問 (他の何かに関連するもの) に対する私の答えの中で、私は彼にそのようなアプローチを使用するのを思いとどまらせると言いましたが、本当の理由は何も言いませんでした. 彼は現在、それが良い考えではない理由を知りたがっています。私はこの質問を使用して、コミュニティが、dbms、コードを使用するなど、別のアプローチを使用するための説得力のある十分な理由のリストを作成できるかどうかを確認しています。 -reuse、url-rewriting、MVC、その他。
3 に答える
記事ごとに個別の ASPX ファイルを生成すると、サーバー リソースの使用効率が低下します。
新しい aspx ファイルはすべて DLL にコンパイルされます。これは、記事をコンパイルするための追加の実行時間のオーバーヘッドと、この新しい DLL を含む新しい AppDomain の再作成によるメモリのオーバーヘッドを意味します。
すべての ASPX ファイルを単一の DLL ファイルにコンパイルするように ASP.Net を構成することは可能ですが、それはさらに悪いことです。新しい記事が生成されるたびに、すべての記事を再コンパイルする必要があります。
より受け入れられる解決策 (それでも、私が推奨するものではありません) は、静的な .html ファイルを生成することです。
.aspx ページは、html (および javascript など) を動的に生成するためのものです。.aspx ページの同じ小さなセットがすべてのブログ エントリの出力を生成する (一連のフィールドに格納される) か、(パフォーマンス上の理由から) 事前に生成された html を db (最適) または .html ページに格納することができます。
ブログ エントリごとに .aspx ページを生成すると、コンテンツを生成するためのツールが生成されます。通常の場合は意味がありません。そのシステムには不必要なオーバーヘッドが発生します。 彼の正確な計画を知らなくても、少なくとも次のいくつかが当てはまると確信できます。
- .aspx ページでのコードの重複、サイトのレイアウト/動作の更新が非常に困難
- 多くの余分な .aspx ページを処理し、常に再コンパイルしなければならない IIS からの実質的かつ不必要なオーバーヘッド。
- コンテンツはfilesにあるため、検索は悪夢になります。セットアップが難しく、効率的ではありません。
- 編集、コメントの追加、モデレートは . . . とても大変。
- セキュリティが複雑になる