0

私の理解によると、DIの実装は

1. ISampleInterface

2.サンプル：ISampleInterface

3.サンプルを使用したISampleInterfaceの構成バインド。

4.そしてコンストラクターインジェクション

ISampleInterface _sampleInterface;

Constructor(ISampleInterface sampleInterface)
{
  _sampleInterface = sampleInterface;
}

残りはDI​​で処理します。

ただし、場合によっては、具体的なインターフェイス実装クラス内で、「新規」初期化が必要になることがあります。それなら私は何をすべきですか？

サンプルクラス内で、

宣言する必要がある場合

private const int _limitSize = 70;
limits = new int[_limitSize];

またはSampleクラス内。インターフェイスメソッドの実装では、次のコードを記述する必要がある場合があります。

Dictionary<string, object[]> arr = new Dictionary<string, object[]>()
{       
    {"name", new string[1]{listName}},          
};

実際の実装

public string ContactListsAdd(string listName)
{
    Dictionary<string, object[]> arr = new Dictionary<string, object[]>()
    {       
        {"name", new string[1]{listName}},          
    };

    return callSomePrivateMethod("contact-lists.add", arr);         
}

だから私の質問は、DIを使用するときにオブジェクトを手動で作成するのは正しいアプローチですか？例のように。それともそれを回避する方法はありますか？

4

1 に答える 1

0

ビジネスロジックを実装する必要があるオブジェクト（データ構造や汎用オブジェクトなど）を手動で作成することには何の問題もありません。ただし、これらはビジネスロジック実装内にカプセル化する必要があります。手動で作成してはならないのは、ビジネスコンポーネント（リポジトリ、サービスなど）です。

依存性注入パターンは、コンポーネントの緩い結合を実現する方法を提供するためにここにあります。そのようなコンポーネントを作成する責任をDIコンテナーに移すので、ビジネスロジック内でそのようなコンポーネントを作成することをいじくり回す必要はありません（ルーズカップリングを使用する傾向がない場合でも、そのようなコンポーネントを作成するときに非常に便利です。コンポーネントが複雑になります）。ただし、使用するすべてのオブジェクトを作成する責任をDIコンテナに移すことはお勧めしません。最終的に、コンポーネントの登録（バインド）は次のようになります。

Bind<IList<string>>().To<List<string>>();
Bind<IList<int>>().To<List<int>>();
Bind<IList<MyObject>>.To<MyObject>(); // what about constructor arguments ???
... and other mess of bindings

そのようなバインディングを維持することは非常に難しいでしょう。また、異なるサイズまたは異なる実装のリストを使用する必要がある場合はどうなりますか？内部クラスオブジェクトのコンストラクター引数はどこで取得しますか？もちろん、条件付きバインディングを使用することもできますが、それは1つの大きな条件付きバインディングの混乱になります。

于 2013-01-29T22:16:25.923 に答える