アプリケーションに、パス トークンを完全修飾パスに変換するクラスがあります。例: のような文字列を取り、"%MYAPPDATA%"を返すことができますC:\Users\user.DOMAIN\AppData\Raoming\MyApp。
または、クラスには、文字列の代わりに列挙型を取ることができる関数へのオーバーロードがあります。例: enum を取り、AppPaths.MyAppDataを返すことができますC:\Users\user.DOMAIN\AppData\Raoming\MyApp。
「ルックアップ テーブル」をどこかに保存する必要がありますが、最適な方法や構造がわかりません。データセットを使用してテーブルをディスクに書き込む必要がありますか? それとも記憶にとどめておきますか？
単一のパス値は、文字列と列挙型にマップできます。インデックスが列挙型の整数値にマップされる配列をメモリに保持し、文字列が渡されたときに配列を検索できると思います。
考え？
特に大きくない限り、メモリ内の配列をそのまま使用します。機能をもう少し増やして、オーバーヘッドを少し増やすには、リストまたは辞書を使用できます。多くの機能 (ただし多くのオーバーヘッド) については、メモリ内データセットを使用できます。
繰り返しますが、たとえば 250 ～ 500 個を超えるアイテムがない限り、プログラムの操作中にディスク ストレージを使用しても意味がありません。レイテンシ (取得時間) とコーディングの両方のオーバーヘッドは、それだけの価値がありません。
もちろん、長期保存用としてディスクに記録を保持することもできます (たとえば、プログラムの開始時にロードするため)。ただし、OS からデータをプルしている場合、これは必要ないかもしれないという問題から見えます。
それはすべて、あなたが望むパフォーマンスに依存します。
データをデータベース テーブル (「生」データ用に 1 つ、キーと列挙の関係用に 2 つ) に格納し、単純な SQL クエリで検索することができます。ただし、基盤となるデータベースとキャッシュ メカニズムによっては、これが最速の方法ではない場合があります。
2 つのインメモリ マップ (辞書?) を使用して、実行時のルックアップを高速化し、起動時にそれらを初期化することもできます。
大きくなることが不可能な場合は、メモリに保持します。そうでない場合は、後で使用するためにデータベース/ファイルに保存します。
もちろん、あなたの使い方次第です。私が見る限り、ユーザー固有のデータへのパスを保存したいと考えています。データのパスを保存できるユーザークラスを持っている可能性がありますか?
if(Directory.Exists(User.Current.AppDataPath))
したがって、すべてのユーザーが自分の AppData がどこにあるかを知っているので、おそらく「ルックアップ テーブル」を取り除くことができます。