2

私はasp.netmvcでWebアプリケーションを実行しています。今、私はヘルプテキスト、eula、プライバシーポリシーなど、多くのテキスト情報を作成しているところです。これらのテキストを保存するための最良の方法がわからないことに気づきました。1.aspxページで直接2.テキストファイルで、ViewData[]を介してテキストをaspxファイルにロードします3.私のSQLデータベースで

オプション3を使用する場合、データベースをどのように設計しますか?たとえば、eula = table x、privacypolicy = table y?

上記のオプションの長所と短所について、いくつかの方向性が必要だと思います。

4

3 に答える 3

1
  1. ASPXページで直接->地獄!。変更を加えるたびに、再コンパイルして公開する必要があります。それはひどい。

  2. テキストファイルを使用すると、このデータが頻繁に変更されない場合にキャッシュを簡単に使用できますが、テキストファイルはさまざまな点でひどいものです。最後に、数十/数百のテキストファイルがあり、何が何を参照しているかわかりません。(したがって、ファイルへのポインタを含むデータベーステーブルを保持する必要があります)。

  3. これは、ここで唯一可能な解決策につながり、すべてをデータベースに保存します。キャッシュを使用することもできます。多くない場合は、すべてをアプリケーション変数に格納します。アプリケーション変数は、iisresetごとにインデックスが再作成されます。

  4. それについてはあまり経験がありませんが、LocalResourcesを使用することをお勧めします。これにより、(必要に応じて)さらに複数の言語をサポートできるようになります。

于 2010-03-21T06:00:57.367 に答える
0

アプリが非常に小さい場合、ページ内にテキストを保持しても問題ないかもしれませんが、アプリとその背後にあるチームが成長するとすぐに、これが問題になる可能性があります。テキストをプロのライターに渡す、翻訳、弁護士による校正など、コードにテキストが混在していると面倒になる

テキストを単純なテキスト ファイルに格納することは、ほとんどのアプリケーションにとって問題ありません。ここで唯一の問題は、アプリケーションの一部が実際にテキストを変更する場合です。このような場合、それらをデータベースに保存することをお勧めします。

ほとんどの場合、テキストをデータベースに保存するのはやり過ぎです。データベースは主に、ACID トランザクションと構造化データのインデックスの利点を提供します。しかし、アプリケーションを通じてテキストが変更されない場合、ACID プロパティはあまり役に立ちません。また、これらがアプリケーションで使用される単なるテキスト ピースである場合は、ピース/ファイルの名前を直接指定できるため、データによって行われるようなインデックス付けも役に立ちません。ただし、データベースにもコストがかかります。データが大量にあると、データベースに実際に属するデータに対してキャッシュが非効率になる可能性があります。トランザクション処理により、パフォーマンス ヒットが発生します。そのため、必要がない場合は、データベースを使用しないでください。

于 2010-03-21T06:17:38.707 に答える
0

これらのファイルが既に存在し、後で変更される可能性がある場合は、データベースからファイル名で参照することをお勧めします。

一方、テキスト自体をデータベースに保存したい場合は、「ページ コンテンツ」のテーブルを用意すると、各タプルが個別のテキストを表す場合にうまく機能します。1 つの属性はテキストの識別子であり、1 つの属性はテキストの識別子です。全文そのもの。

どちらを選択する場合でも、 DRY の原則に従うことをお勧めします。簡単に管理できる正規の場所を 1 つ選択し、アプリケーション全体でその場所に固執します。

于 2010-03-21T06:19:32.153 に答える