3

使っています

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\MyProgram"

私のプログラムで使用されるいくつかのファイルを保存するためのパスとして。アプリケーション全体に同じコードスニペットを貼り付けないようにしたいと思います。

私はそれを確認する必要があります：

  • 一度設定したパスを誤って変更することはできません
  • それを必要とするクラスはそれにアクセスできます。

私は考えました：

  • シングルトンにする
  • コンストラクターの依存性注入を使用する
  • プロパティ依存性注入の使用
  • AOPを使用して、必要な場所にパスを作成します。

それぞれに長所と短所があります。

シングルトンはみんなのお気に入りのむち打ちの少年です。私はそれを使用することに反対していませんが、可能であればそれを避ける正当な理由があります。

CastleWindsorを介したコンストラクターインジェクションをすでに頻繁に使用しています。ただし、これはパス文字列であり、Windsorはシステムタイプの依存関係を適切に処理しません。私はいつでもそれをクラスでラップすることができましたが、それは文字列値を渡すような単純なものにはやり過ぎのようです。いずれにせよ、このルートは、それが使用される各クラスにさらに別のコンストラクター引数を追加します。

この場合のプロパティインジェクションで見られる問題は、値が設定されている場所から必要な場所への間接参照が大量にあることです。それが使用されたすべての場所に到達するには、非常に長い仲介者の列が必要になります。

AOPは有望に見えますが、とにかくロギングにAOPを使用することを計画しているので、これは少なくとも単純な解決策のように聞こえます。

私が考慮していない他のオプションはありますか？検討したオプションの評価でベースから外れていますか？

4

5 に答える 5

3

Environment十分に強いニーズがあるときに、自分のプロジェクトのように静的クラスを作成することに問題が発生したことは一度もありません。

MyAppEnvironment.ApplicationFolder

インジェクションを使用して値を渡す場合は、a）値を保持するためだけにクラスを作成するか、b）文字列を渡すかのいずれかです。あなたの値は一定でなければならないので、後者は悪いです。前者は有効ですが、有効な値は1つしかないため、かなりのオーバーヘッドのように見えます（本当に必要な場合は、テスト用にその値をモック/偽造できます）。

環境クラスを注入できると思いますが、私にとってはこれはやり過ぎのようです。

于 2010-03-17T16:31:46.897 に答える
1

あなたが持っているものは、アプリケーション内のグローバル設定に相当するようです。AOP oコンストラクターインジェクションを使用してこの依存関係を回避することは、より単純なソリューションでうまくいくため、かなりやり過ぎのように思われます。

ここでの私の好みは、静的クラスで静的プロパティを使用することです。複数のセットを防ぐ特定の書き込みルーチンを追加します。例えば ​​...

public static class GlobalSettings {
  private static string s_path;
  public static string Path { get { return s_path; } }
  public static void UpdatePath(string path) {
    if ( s_path != null || path == null ) { throw ... }
    s_path = path;
  }
}
于 2010-03-17T16:34:51.040 に答える
0

標準の.netアプリケーションを使用している場合は、すでに設定（class）が必要です。新しい設定を作成し、その値をデフォルト値などに設定できます。

于 2010-03-17T16:29:16.283 に答える
0

IMyAppConfigコンストラクターは、この種すべてのものの単なるラッパーである型のクラスを注入します。

于 2010-03-17T16:34:08.997 に答える
0

私のプロセスは、常に次のような質問をすることです。どのようなことが変わる可能性がありますか？それらが変化したときに、何が最も少ない痛みを生み出すでしょうか？他のシステムで再利用できる部分と、再利用の苦痛を最小限に抑えるにはどうすればよいですか？基本的に、これらのものを可能な限り切り離すにはどうすればよいでしょうか。

それを念頭に置いて、答えは実際にあなたが取り組んでいるシステムの詳細に基づいています。

このパスを使用するプロセスでは、パラメーターとして渡す可能性があります。これは、パスの使用を開始するアクションから始まります。各メソッドは「1つのことをうまく行う」必要があり、パスがその一部である場合は、パラメーターである必要があります。アクションを開始するクラス（およびそのクラスの存続期間を制御するクラスなど）では、パスをコンストラクターの一部にする可能性があります。

これは私が過去に使用した方法であり、それは私によく役立っています。たとえば、あるアプリケーションでこのアプローチを採用した後、ユーザーがパス設定を変更できるようにする必要があることを発見しました。このアーキテクチャに従う（そしてシングルトンを回避する）ことにより、パスをすでに使用していたオブジェクトはエラーなしで古いパスを引き続き使用できますが、変更の時点から新しいパスが正しく使用されました。それはうまくいきました。

また、この特定の詳細に依存することなく、クラスを新しいプロジェクトに移行できます。

于 2010-03-17T16:44:18.270 に答える