27

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

これはパフォーマンスに関して良い考えですか?を使用AppSettingsすることは、.Net アプリを作成するときに構成設定を保存してアクセスするための「正しい方法」であると思われますが、この方法は一定の負荷を意図していないのではないかと心配しています (少なくとも設定が常に読み取られるという点では)。

誰かがこれを経験したことがあるなら、私は大いに感謝します。

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

これは Web アプリケーションではないため、データベースをアプリケーションに接続することは、単に構成設定を保存するためだけにやり過ぎかもしれません。これは Windows フォーム アプリケーションです。

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

更新 2:Propertiesアプリケーション (データベースなど) に追加のレイヤーを追加する必要がなく、確かに良いソリューションのように見えるため、lomaxx の回答を受け入れました。プロパティを使用する場合、他の人が提案したすべてのキャッシュが既に行われています。これは、すべての変更とその後の読み取りがすべてメモリ内で行われることを意味し、非常に高速になります。プロパティは、明示的に指示された場合にのみ変更をディスクに書き込みます。つまり、実行時にオンザフライで構成設定を変更し、プログラムの終了時にディスクへの最終的な保存のみを行うことができます。

必要な負荷を実際に処理できるかどうかを確認するために、ラップトップでテストを行ったところ、プロパティを使用して毎秒 750,000 回の読み取りと 7,500 回の書き込みを行うことができました。これは、私のアプリケーションが必要とするレベルをはるかに超えているため、パフォーマンスに影響を与えずにプロパティを使用しても安全だと感じています

4

8 に答える 8

10

winforms アプリを使用しているため、それが .net 2.0 の場合、この目的のために設計されたユーザー設定システム (プロパティと呼ばれる) が実際にあります。MSDN のこの記事には、これに関するかなり良い紹介があります。

それでもパフォーマンスが心配な場合は、SQLite に似ているSQL Compact Editionをご覧ください。これは Microsoft が提供するものであり、winforms で非常にうまく機能し、Linq で動作させる機能さえあります。

于 2008-08-07T00:45:37.393 に答える
2

SQLite を確認してください。この特定のシナリオに適したオプションのようです。

于 2008-08-07T00:41:38.977 に答える
2

ディラン、

この目的でアプリケーション構成ファイルを使用しないでください。構成ファイルへの読み取りおよび書き込み中の同時実行の問題について心配する必要が少なくなるため、SQL DB (SQLite、MySQL、MSSQL など) を使用してください。

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

于 2008-08-07T00:56:26.933 に答える
2

appSettings は、実際にあなたがしようとしていることを意図したものではありません。

.NET アプリケーションが起動すると、app.config ファイルが読み込まれ、その内容がメモリにキャッシュされます。そのため、app.config ファイルに書き込んだ後、何らかの方法でランタイムに強制的に app.config ファイルを再解析させ、設定を再度キャッシュできるようにする必要があります。これは不要です

最善の方法は、データベースを使用して構成設定を保存することです。

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

于 2008-08-07T01:10:36.720 に答える
1

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

于 2008-08-07T00:26:39.770 に答える
1

ユーザーデータを保存するために構成ファイルを使用しません。デシベルを使用します。

于 2008-08-07T00:43:11.297 に答える
0

ユーザーの設定をデータベースに保存しない理由をお聞かせください。

一般的に、私は appSettings セクションで非常にまれにしか変更されないアプリケーション設定を保存します (デフォルトの電子メール アドレス エラー ログの送信先、自動的にログアウトされるまでの分数など)。これの範囲は実際にはアプリケーションにあります。 、ユーザーではなく、一般的に展開設定に使用されます。

于 2008-08-07T00:27:36.807 に答える
0

私が検討していることの 1 つは、読み取り時に appsettings をキャッシュし、書き込み時にキャッシュから設定をフラッシュすることです。これにより、サーバーが appSettings を処理するために処理する必要がある実際の負荷の量を最小限に抑えることができます。

また、可能であれば、appSettings をconfigSectionsに分割して、書き込み関連の設定を読み取ったりキャッシュしたりできるようにすることを検討してください。

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

于 2008-08-07T00:28:58.877 に答える