Properties.Settings.Defaultに依存性注入を使用しますか？

Question

Properties.Settings.Defaultをクラス内で依存関係として使用することを考慮する必要がありますか？

例えば：

public class Foo 
{ 
    private _settings; 
    private bool _myBool; 

    public Foo(Settings settings) 
    { 
     this._settings = settings; 
     this._myBool = this._settings.MyBool; 
    } 
} 

。
。

またはSettingsのアプリケーションをグローバルなアプリケーションとして使用することをお勧めしますか？

例えば：

public class Foo 
{ 
    private bool _myBool; 

    public Foo() 
    { 
     this._myBool = Properties.Settings.Default.MyBool; 
    } 
} 

Answer 1

設定をクラスにカプセル化し、そのためのインターフェイスを用意することができます。あなたの設定がどこから来るかは、単体テストなどのために変更することができます。 IoCコンテナも使用している場合は、設定をコンテナに登録してください。

私はConfigurationManagerとWebConfigurationManagerのためにこれを行い、テスト用の設定を注入することができます。 Nathan Gloyn has wrapped the adapters and interface up already in a projectも使用できます。

Answer 2

彼らは、依存関係として渡す必要があります。あなたの例＃2のユニットテストを介してその設定のセットを変更したい場合のシナリオを想像してみましょう。静的プロパティゲッターに複雑なスイッチロジックを持っていなければなりません。

多くのIoCコンテナは、あなたのためのクラスを注入する際に、シングルトンの実装を提供することさえできます。

Answer 3

I「は、上記のいずれ」を選択しないと直接ブール値を挿入します：

public class Foo 
{ 
    private readonly bool _myBool; 

    public Foo(bool myBool) 
    { 
     _myBool = myBool; 
    } 
} 

これは、ブール値の取得をサポートする任意のインフラの知識からFooを分離します。 Fooには、設定オブジェクトに依存して複雑さを導入する理由はありません。特に、他の無関係な値が含まれている場合は特にそうです。