1

私は大きなクラス階層を持っています。アプリが起動したら、 UnityContainer オブジェクトを初期化して構成します。その後、私は常にコンストラクターを介して階層内の別のクラスに渡します。このようなもの ：

Unity コンテナーには、登録として次のクラスがあります: IClassA、IClassB、IClassC、IClassD

インターフェイスのすべての具体的な実装には、IUnityContainer パラメーターを持つコンストラクターがあります。例えば、

    public class ClassA : IClassA
    {

        public ClassA(IUnityContainer unityContainer)
        {
        }
    }

そのため、何らかのクラスの新しいインスタンスを作成するたびに、IUnityContainer のオブジェクトを渡す必要があります。

IUnityContainer オブジェクトをコンストラクターのパラメーターとして渡す量を減らすことはできますか? 多分 Dependency 属性を使用して？

4

2 に答える 2

8

はい、減らすべきです。

0 に減らす必要があります。

このように DI コンテナーを使用することは、悪い習慣です。DI コンテナーを魔法のスーパー ファクトリーとして扱わないでください。

コンポジションルートでアプリケーションを簡単に作成できるようにするためにのみ、コンテナーを使用する必要があります。これを読んでください。

コードは、それが DI コンテナーで構成されていることを認識してはなりません。コンテナーは単なるテクノロジーであり、DI はテクニックです。コンテナなしでもアプリケーションを作成できるはずです。

では、どうすれば減らすことができるのでしょうか。このような：

public class ClassA : IClassA
{
    public ClassA()
    {
    }
}

次に、ClassA何か（依存関係、インターフェース）が必要な場合は、たとえばコンストラクターを介してそれを注入する必要があります。

public class ClassA : IClassA
{
    private readonly IComponent _component;        

    public ClassA(IComponent component)
    {
        _component = component;
    }
}

プロパティ注入、メソッド注入、アンビエント コンテキストなど、別の注入パターンも使用できます。

質問のようにコンテナを使用すると、実際のクラスのすべての依存関係が非表示になります。コンテナーを使用してアドホックに何かを解決するため、その実際のクラスが機能する必要があるものを理解することはできません。依存関係を注入しないため、依存関係の注入に完全に反対します。非常に危険であり、複雑さを大幅に増加させる汎用ファクトリ (何でも要求できます) を注入するだけです。

この本を強くお勧めします: .NET での依存性注入 - マーク シーマン

于 2012-09-14T11:42:51.030 に答える
3

あなたがしていることは、コンテナーを ServiceLocator として悪用することです。これは、最新のアプリケーション アーキテクチャではアンチパターンと見なされます。

代わりに、適切な依存性注入を使用してください。Martin Fowler がこのパターンについて適切に紹介しています。

Mark Seemann は、 .NET における Dependency Injectionというトピックに関する非常に優れた本を書きました。

@PeterPorfy がすでに指摘しているように、コンポジション ルートの概念は重要です。すべての依存関係をコンテナーに登録し、そこでアプリケーションまたはサービスのルート オブジェクトを解決してキックオフします。

その構成ルート外のクラスにコンテナーを渡すことは決してありません!

于 2012-09-14T11:54:29.423 に答える