私が開発および保守しているプロジェクトの範囲は非常に広いです。 このため、彼らは依存性注入パターンを積極的に使用しています。

実装の最も重要な部分はコンポジションルートです。 コンポジションルートは通常、 Register-Resolve-Releaseパターンを使用して実行されます。 Composition Rootの読みやすくコンパクトで表現力豊かな説明のために、 DIコンテナーなどのツールが通常使用されます。選択があれば、 Autofacを使用することを好みます。

このコンテナは利便性の面で当然と考えられていますが、開発者には多くの質問や苦情さえあります。 私自身の実践からの最も一般的な問題については、Autofacをコンポジションルート構成ツールとして使用することに伴うほとんどすべての問題を軽減または完全に解消する方法を説明します。

多くの構成エラーは、実行時にのみ検出されます。

Asメソッドのタイプセーフバージョン

最大の効果を持つ最小の製品：

public static IRegistrationBuilder<T, SimpleActivatorData, SingleRegistrationStyle> AsStrict<T>( this IRegistrationBuilder<T, SimpleActivatorData, SingleRegistrationStyle> registrationBuilder) { return registrationBuilder.As<T>(); } public static IRegistrationBuilder<T, ConcreteReflectionActivatorData, SingleRegistrationStyle> AsStrict<T>( this IRegistrationBuilder<T, ConcreteReflectionActivatorData, SingleRegistrationStyle> registrationBuilder) { return registrationBuilder.As<T>(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C＃は一般化のための部分的なタイプの自動出力をサポートしていないため、アクティベーションデータと登録スタイルの一般的な組み合わせごとに1行のメソッドを記述する必要があります。

しかし、唯一のプラスはすべてのコストを負担します。現在、インターフェイスのタイプと実装の不一致により、コンパイルエラーが発生します。

AsStrictへの移行を容易にする再シャープ見本サンプル

すでにかなり大きなプロジェクトがある場合は、 カスタムResharper置換パターンを使用して、タイプセーフバージョンのAsの実装を促進できます 。

シングルライナーごとに1つのサンプルを取得しました。 検索式と置換式は誰でも同じです。

  //  $builder$.As<$type$>() builder - expression placeholder type - type placeholder //  $builder$.AsStrict<$type>()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、各サンプルの$ builder $の型制限は異なります。

  IRegistrationBuilder<$type$, SimpleActivatorData, SingleRegistrationStyle> IRegistrationBuilder<$type$, ConcreteReflection, SingleRegistrationStyle>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RegisterTypeの代わりにRegisterを使用する

これも役に立つかもしれません：

1. 実装の作成を微調整できます
2. 型の登録と比較して、明示的なパラメーターの転送は簡単で明確です
3. 実装を解決するときのパフォーマンスの向上

...しかし、欠点もあります：

1. クラスコンストラクターシグネチャを変更するには、登録コードを修正する必要があります。
2. 型の登録は、最も単純なデリゲートの登録よりも明らかにコンパクトです

どのタイプがデリゲートを介して登録されているかを理解することは困難です

RegisterType <>（）が同一のインターフェイスおよび実装タイプで使用されない限り、AsStrictを使用してインターフェイスタイプを指定することが常に最善です。 インターフェイスのタイプとデリゲートによって返される値に互換性がない場合、コンパイルエラーはボーナスになります。

実装の委任登録はスペースを取りすぎます

特に、登録のセットが画面に収まらなくなることが原因である場合は、複数行になることがあります。

最も簡単な方法は、デリゲートを介してContainerBuilderの拡張メソッドに登録を割り当てることです。

 public static IRegistrationBuilder<Implementation, SimpleActivatorData, SingleRegistrationStyle> RegisterImplementation( this ContainerBuilder builder) { return builder.Register(c => { //     // ... return implementation; }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前の方法と組み合わせて使用​​することをお勧めします

 builder.RegisterImplementation().AsStrict<IInterface>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前付き代理登録を見つけるのが難しい

Autofacはauto-bindingを介してこのようなデリゲートの値を解決できますが、いくつかのニュアンスがあります。

1. 匿名デリゲート（Func）のパラメーター、コンストラクターパラメーターがタイプごとにマッピングされている場合、名前付きデリゲートのパラメーターは名前ごとにマッピングされます
2. 匿名デリゲートによって返された値の型がすぐに表示される場合、名前付きのものについては、まずその定義に移動します

その結果、名前付きデリゲートは、適切な登録を検索するときとコンストラクターパラメーターを比較するときの2つの追加レベルの間接性を直ちに作成します。

名前付きデリゲートのオプトアウト

コンストラクターに同じ型のパラメーターがない場合、匿名デリゲートで置き換えることは基本です。

それ以外の場合は、個別に登録する必要のある構造、クラス、またはインターフェース（EventArgsなど）で多くのパラメーターを置き換えることができます。

名前付きデリゲートの明示的な登録

このオプションは、DIコンテナからのビジネスエンティティの独立性の観点からはより正確であり、追加の間接化を正常に排除しますが、より詳細な登録が必要です。

コンポーネントの初期化に必要な順序を維持することは困難です

この問題は、DIパターンに基づいて構築されたプロジェクトにはないように思われます。 ただし、外部フレームワーク、ライブラリ、異なる設計の個別のクラスを使用することが常に必要になる場合があります。 継承コードもしばしば貢献します。

従来、Dependency Injectionパターンの場合、シーケンスは依存関係に置き換えられます。

RegisterInstanceを修正

RegisterInstanceへの呼び出しは事実上のResolveであり、登録中であってはなりません。 事前に作成された実装でさえ、SingleInstanceとしてより適切に登録されます。

カスタム初期化クラスの作成

コンポジションルート内でアトミックと見なされる初期化アクションに対して、個別のクラスが作成されます。 アクション自体は、このクラスのコンストラクターで実行されます。

ファイナライズが必要な場合-通常のIDisposableが実装されます

このような各クラスは、IInitializerマーカーインターフェイスを継承します。

コンポジションルートは、Resolveを

 context.Resolve<IEnumerable<IInitialization>>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化の順序

一部の初期化アクションを他のアクションよりも後に実行する必要がある場合、後のアクションでは、前のアクションで実装されたインターフェースへのリンクを使用するだけで十分です。 そのようなリンクがない場合（アクションの特定の順序の要件のみが存在する場合）、以前のアクションの初期化クラスはマーカーインターフェイスでマークされ、対応するタイプのパラメーターが「late」初期化のコンストラクターに追加されます。

その結果、次のパンが取得されます。

1. 複雑な初期化プロセスは、小さく、シンプルで、実装しやすく、再利用可能な部分に分かれています
2. Autofac自体は、初期化子を追加、削除、または変更するときに正しい初期化順序を調整します
3. Autofacは、この注文の要件のサイクルと中断を自動的に検出します
4. 実際、RRRパターンの実装は、特定のモジュールやプロジェクトに依存しない別のクラスに簡単に移動できます

唯一の欠点は、初期化全体の視覚化が失われることです。これは、個人的には問題を考慮していません。これは、思慮深いログによって簡単に補足されるためです。

構成ルートが大きすぎる

Autofacのドキュメントでは、 Moduleクラスの独自の子孫を使用することを推奨しています。 それは少し役立ちます。むしろ、少し役立ちます。 問題は、モジュール自体が互いに分離されていないことです。 あるモジュールに登録されたクラスが別のモジュールに依存することを妨げるものは何もありません。 また、同じインターフェイスの実装を別のモジュールに再登録することも問題ではありません。

分解構成ルート

Autofacを使用すると、LifetimeScopeを作成するときに、ドキュメント機能の登録機能で非常に控えめに説明されている方法を使用して、単一のモノリシックコンポジションルートをルートと子の組み合わせに分割できます。

子アセンブリポイントを使用すると、まったく同じ操作を実行して、特定の各アセンブリポイントの登録の説明が自分の観点から妥当なフレームワーク内に収まるまで繰り返すことができます（私にとってはこれが1つの画面です）。

InstanceForLifetimeScopeを修正

LifetimeScopeの作成時にコンポーネント登録の使用を開始すると、すぐに別のおいしい小さなパン、 つまりInstanceForLifetimeScopeおよびInstancePerMatchedLifetimeScopeの完全な拒否を取得できます。 これらのコンポーネントをネイティブLifetimeScopeのSingleInstanceとして登録するだけです。 途中で、LifetimeScopeタグへの依存がなくなり、必要に応じてそれらを使用することが可能になります。私の場合、各LifetimeScopeはタグとして人間が読める一意の名前を取得します。

子のコンポジションルートの便利な登録

残念ながら、 BeginLifetimeScopeを直接使用するのは簡単ではありません 。 しかし、この悲しみは次の方法で解決できます：

 /// <summary> ///       /// </summary> /// <typeparam name="T"> </typeparam> /// <typeparam name="TParameter">    ( )</typeparam> /// <param name="builder"> </param> /// <param name="innerScopeTagResolver">    </param> /// <param name="innerScopeBuilder">       -    </param> /// <param name="factory">         </param> /// <returns></returns> public static IRegistrationBuilder<Func<TParameter, T>, SimpleActivatorData, SingleRegistrationStyle> RegisterWithInheritedScope<T, TParameter>( this ContainerBuilder builder, Func<IComponentContext, TParameter, object> innerScopeTagResolver, Action<ContainerBuilder, IComponentContext, TParameter> innerScopeBuilder, Func<IComponentContext, IComponentContext, TParameter, T> factory) { return builder.Register<Func<TParameter, T>>(c => p => { var innerScope = c.Resolve<ILifetimeScope>().BeginLifetimeScope(innerScopeTagResolver(c, p), b => innerScopeBuilder(b, c, p)); return factory(c, innerScope, p); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは最も一般的な使用例であり、子スコープのパラメーターの受け渡しとタグ生成を使用してファクトリを作成できます（Tインターフェイスを実装するオブジェクトごとに個別の子スコープが作成されます）。

重要なポイント：内部スコープのタイムリーなクリーニングは自分で行う必要があります。 私の以前の記事の1つからのアイデアは、これに役立ちます。

長所：

1. 外部スコープは内部に依存しません。
2. 外部スコープに登録されているすべてのものは、内部で利用可能です。
3. 内部スコープの登録は、外部スコープと簡単にオーバーラップできます。

短所：

1. 内部スコープは、実装の継承の魅力をすべてロードします

次のメソッドを使用すると、内部スコープの外部への依存を完全に制御できます（完全に分離されたオプションを含む）。

 public static IRegistrationBuilder<Func<TParameter, T>, SimpleActivatorData, SingleRegistrationStyle> RegisterWithIsolatedScope<T, TParameter>( this ContainerBuilder builder, Func<IComponentContext, TParameter, object> innerScopeTagResolver, Action<ContainerBuilder, IComponentContext, TParameter> innerScopeBuilder, Func<IComponentContext, IComponentContext, TParameter, T> factory) { return builder.Register<Func<TParameter, T>>(c => p => { var innerScope = new ContainerBuilder().Build().BeginLifetimeScope( innerScopeTagResolver(c, p), b => innerScopeBuilder(b, c, p)); return factory(c, innerScope, p); }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめ

1. 複雑なケースで依存性注入を完全に使用するには、適切なツール（コンテナー）とその使用における開発者の十分に発達したスキルの両方が必要です。
2. Autofacのような柔軟で強力かつ十分に文書化されたコンテナでさえ、特定のプロジェクトおよび特定のチームのニーズに合わせてファイルをいくらか改良する必要があります。
3. Autofacを使用したアセンブリポイントの分解は非常に可能です。公式ドキュメントには記載されていませんが、このようなアイデアの実装は比較的簡単です。
4. Autofacモジュールはカプセル化を提供しないため、分解には適していません。

PS：エキストラと批判は伝統的に歓迎されています。