いくつかのサービス パラメーターのディクショナリを使用する WCF サービスがあります。このディクショナリは、ローカル ディスクに保存された XML ファイルを解析して作成されます。FileSystemWatcherファイルの更新を可能にするために、ファイルが変更された場合に辞書を再作成するためにa を使用したいと考えています。
この仕組みは他にも使っていますし、サービスでも使いたいと思っていました。私の問題は、私の理解では、WCF は要求ごとにサービス クラスのインスタンスを作成し (これは構成可能であることはわかっていますが、要求ごとに使用します)、ディクショナリを保持する場所に保持したいということです。インスタンスがリクエストの処理を完了した後のメモリ。
これは可能で、XML ファイルの解析と辞書の保存のためのロジックを配置するのに最適な場所はどこでしょうか?
カスタム構成セクションを作成して、 ConfigurationSectionを使用して Web.config ファイルに XML を格納し、構成ファイルから簡単に読み取ることができます。構成値は、フレームワークによってキャッシュされます。また、このアプローチではファイルウォッチャーは必要ありません。Web.config に「触れる」と、アプリケーションが自動的に再起動され、新しい値がキャッシュに読み込まれます。
辞書を静的メンバーに格納し、静的コンストラクターまたは遅延で初期化できます。
サービスが iis でホストされている場合は、iis がホスト プロセスのライフサイクルを処理することに注意してください。これは、アプリ ドメインが再作成されるときに辞書がリロードされることを意味します。
まず、msdn によると、辞書クラスを使用していると仮定します。コレクションが変更されない限り、辞書は複数のリーダーを同時にサポートできます。それでも、コレクションの列挙は本質的にスレッドセーフな手順ではありません。列挙が書き込みアクセスと競合するまれなケースでは、列挙全体の間、コレクションをロックする必要があります。読み取りおよび書き込みのために複数のスレッドがコレクションにアクセスできるようにするには、独自の同期を実装する必要があります。
スレッドセーフな代替手段については、ConcurrentDictionary を参照してください。
次に、ディクショナリをラップするシングルトン クラスを作成して、複数の要求を処理するアプリ ドメインに対してディクショナリのインスタンスを 1 つだけインスタンス化することができます。シングルトンを構築するには多くの方法があり、どの実装を選択するかは使用パターンによって異なります。C# とシングルトンをググって、多くの選択肢から 1 つを選択してください。