0

以下を検討してください。

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) { ... }
}

私のサービスの多くが複数の共通コンポーネントに依存していることに気づき、Service コンストラクターでのコードの繰り返しを節約するために、以下のようなキャッチオール ソリューション (すべて Windsor 経由で配線) を実装することを考えています。

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 クラスを作成することもできます。

public class ServiceBase
{
    public DependancyA A { get; set; }
    public DependancyB B { get; set; }
    public DependancyC C { get; set; }
    public DependancyD D { get; set; }
}

public class Service1 : ServiceBase {}

本当の問題は、これがサービスのより広い設計上の問題を浮き彫りにしているのかということです。

おそらく私は DI を使いすぎているのかもしれませんが、これらはすべて本物の依存関係です。

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

4

2 に答える 2

1

より広い文脈なしにこの問題について話すのは難しいですが、あまりにも細かい依存関係を扱っている可能性があります。4 つの依存関係は一緒に属していますか? それらは 1 つのまとまりのある全体として理にかなっていますか?

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

そうでない場合は、アーキテクチャの壁にぶつかっている可能性があります。1 つ以上の (暗黙的に存在する) エンティティに置かれるべき責任が他のエンティティに関連付けられるように、ドメインを分割している可能性があります。この場合、ドメインを調べて、これらの繰り返し発生する暗黙的なエンティティを特定し、それらを明示的にして、動作をそれらに移動する必要があります。ただし、これははるかに難しい問題であり、ドメインとアプリケーションに非常に固有です。

そして、それはIoCとは何の関係もありません

于 2009-05-13T11:08:05.827 に答える
1

サービスへの依存関係が多すぎるということは、サービスがあまりにも多くのことを行っていることを示している可能性があります。言い換えれば、おそらく単一責任の原則に違反しています。

于 2009-05-13T14:02:57.663 に答える