IOC - 複数の依存関係の注入

Question

は下記考えてみましょう：

public class DependencyA {} 
public class DependencyB {} 
public class DependencyC {} 
public class DependencyD {} 

public class Service1 
{ 
    public Service1(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service2 
{ 
    public Service2(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 
public class Service3 
{ 
    public Service3(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... } 
} 

私は私のサービスの多くは、複数の共通のコンポーネントに依存していることを発見していて、以下のようにすべてのソリューションは、（すべてのアップ有線キャッチを実装することを考えていますウィンザーを介して）サービスコンストラクタのコードの繰り返しを保存します。

public class DependencyContainer 
{ 
    public DependencyA A { get; set; } 
    public DependencyB B { get; set; } 
    public DependencyC C { get; set; } 
    public DependencyD D { get; set; } 
} 

public class Service1 
{ 
    public Service1 (DependencyContainer container) { ... } 
} 

また、ServiceBaseクラスを作成することもできます。

これは、サービスでのより広いデザイン問題を強調していますか？

おそらく私はDIを遠くに持っていますが、これらはすべて本物の依存関係です。

もしそうなら、どうすればこのコードを書くことができますか？ 提案されたソリューションがこの目標を達成する有効な方法でない場合は、

Answer 1

を何の関係もありません。言い換えれば、恐らくそれはおそらく単一責任原則に違反しています。

Answer 2

より広い文脈がな​​ければ問題について話すのは難しいですが、あまり細かい粒界の依存関係を扱っているかもしれません。 4つの依存関係は一緒に属していますか？彼らは一貫性のある全体として理にかなっていますか？

もしそうなら、あなたのアプローチは非常に有効です。

もしそうでなければ、あなたのアーキテクチャの壁に当っているかもしれません。 1つまたは複数の（暗黙的に存在する）エンティティに入れるべき責任が他のエンティティに関連付けられるように、ドメインを分割することができます。この場合、ドメインを調べて、これらの繰り返し暗黙のエンティティを識別し、それらを明示的にしてその中に振る舞わせる必要があります。しかしこれははるかに難しい問題であり、ドメインやアプリケーションに固有のものです。

そして、それはあなたのサービスがあまりにも多くのことをやっていることを示しているかもしれないあなたのサービスにあまりにも多くの依存関係を持つのIoC

で