ConfigurationManager.AppSettingsパフォーマンスに関する懸念

Question

自分のアプリケーションのapp.configセクション（ConfigurationManager.AppSettingsクラスを使用）にすべての設定を保存する予定です。ユーザーがアプリのUI（チェックボックスのチェック、ラジオボタンの選択など）を使用して設定を変更すると、その変更をAppSettingsに書き込む予定です。同時に、プログラムの実行中は、常にデータを処理するプロセスから常にAppSettingsにアクセスする予定です。 UIを介して設定を変更すると、データ処理にリアルタイムで影響する必要があります。そのため、プロセスは常にAppSettingsにアクセスします。

これはパフォーマンスに関しては良い考えですか？ AppSettingsを使用すると、.NETアプリケーションを作成するときに構成設定を保存してアクセスする "正しい方法"になっているはずですが、この方法は常に一定の読み込みを意図したものではないと心配しています。

誰もがこのような経験があれば、私は非常に入力を感謝します。

更新：私はおそらくいくつかの点を明確にする必要があります。

これはWebアプリケーションではないため、アプリケーションにデータベースを接続すると、構成設定を保存するだけで過度の作業になる可能性があります。これはWindowsフォームアプリケーションです。

MSDNドキュメントによると、ConfigurationManagerは、アプリケーションレベルの設定だけでなくユーザー設定も格納するためのものです。 （特に重要な場合には、例えば、アプリケーションが部分信頼アプリケーションとしてインストールされます。）

アップデート2：Propertiesは確かに良い解決策のように見えるんので、私は任意の追加の層を追加することなく、lomaxxの答えを受け入れ私のアプリケーション（データベースなど）に転送します。プロパティを使用する場合、他のユーザーが提案したすべてのキャッシングは既に実行されています。つまり、変更やそれに続く読み込みはすべてメモリ上で行われ、非常に高速になります。プロパティは、明示的に指示したときにのみ変更をディスクに書き込みます。つまり、実行時に設定設定をオンザフライで変更してから、プログラムが終了したときにディスクに最後に保存するだけです。

私が必要とする負荷を実際に処理できるかどうかを検証するために、私は自分のラップトップでいくつかのテストを行い、プロパティを使用して750,000回の読み込みと7,500回の書き込みができました。それはこれまで以上に私のアプリケーションを私はパフォーマンスに影響を与えずにプロパティを使用することでかなり安全だと感じることに近づくだろう。

Answer 1

あなたがwinformsアプリケーションを使用しているので、それが.net 2.0にある場合、実際にはこの目的のために設計されたユーザー設定システム（プロパティ）があります。それでもパフォーマンス心配している場合はThis article on MSDNこの

にかなり良い導入を持っていることは、その後のSQLiteに似ていますが、私はリサイズで非常にうまくプレーを発見したマイクロソフト製品ですとさえありますSQL Compact Editionを見てみましょうあなたは時の同時実行の問題についてはあまり心配する必要がありますので、SQL DB（SQLiteのは、MySQL、MSSQLを、何でも）を使用し、この目的のためにアプリケーションの設定ファイルを使用しないでくださいmake it work with Linq

Answer 2

私が間違っていると誰かが私を修正しますが、AppSettingsは通常、これらのタイプの構成設定に使用されるとは思われません。通常は、静的な設定（データベース接続文字列、ファイルパスなど）のみを入れます。カスタマイズ可能なユーザー設定を保存する場合は、別の環境設定ファイルを作成するか、理想的にはそれらの設定をデータベースに保存することをお勧めします。

Answer 3

データベースにユーザーの設定を保存しない理由について聞かれますか？

一般に、appSettingsセクションではほとんど変更されないアプリケーション設定を保存します（デフォルトのメールアドレスエラーログが送信され、自動的にログアウトされる時間など）。ユーザーではなくアプリケーションにあり、一般的に展開設定に使用されます。

Answer 4

私が見ていることの1つは、読み込み時にappsettingsをキャッシュしてから、サーバーがappSettingsを処理するために処理しなければならない実際の負荷の量を最小限に抑えるべき書き込みのキャッシュから設定をフラッシュすることです。

また可能であれば、appSettingsをconfigSectionsに分割して、書き込みおよびキャッシュ関連の設定を読み取ることができます。

これまで述べてきたように、実際にはユーザー設定を保存しているように見えますが、アプリケーション設定ではなく、これらの値をデータベースに保存することを検討することを真剣に検討します。

Answer 5

SQLiteをチェックすると、このシナリオでは良い選択肢のようです。

Answer 6

ユーザーデータを格納するための設定ファイルは使用しません。 dbを使用します。

Answer 7

ディランの能力、

configファイルを読み書きします。

また、保存するデータの種類の柔軟性も向上します。 appSettingsセクションは、時間の経過やアプリの成熟に伴って成長するキー/値リストです。あなたはカスタム設定セクションを使用することができますが、デザインに関しては新しい問題領域になります。

Answer 8

appSettingsは実際にしようとしているものではありません。

.NETアプリケーションが起動すると、app.configファイルが読み込まれ、その内容がメモリにキャッシュされます。そのため、app.configファイルに書き込んだ後は、実行時にapp.configファイルを再解析して設定を再度キャッシュできるようにする必要があります。これは不要です

ベスト・アプローチは、構成設定を保管するためにデータベースを使用することです。

データベースの使用を除いて、外部XML設定ファイルを簡単に設定できます。アプリケーションが起動すると、その内容をNameValueCollectionオブジェクトまたはHashTableオブジェクトにキャッシュできます。設定を変更/追加すると、そのキャッシュされたコピーに変更が加えられます。アプリケーションがシャットダウンするか、または適切な時間間隔で、キャッシュの内容をファイルに書き戻すことができます。