Mark Seemann の著書Dependency Injection in .NET では、より多くの人々が AUTO-REGISTRATION をサポートする DI コンテナーを使用しており、コンテナーが必要な具象型のインスタンスを事前の構成をほとんど行わずに解決できると述べており、これは規則にうまく適合しています。オーバー コンフィギュレーション アーキテクチャ アプローチ。しかし、これにより、難読化ツールを使用した場合、コードベースが壊れて、規則が変更されたためにコンテナーが失敗するのではないかと思いました。
2 に答える
アプリケーション アセンブリを難読化した方法で出荷する場合でも、通常は引き続き依存関係の挿入を使用できます。通常、型を登録するためにジェネリック型付け ( などRegister<IService, Impl>()
) またはtypeof
引数 ( など) を使用するため、これは機能Register(typeof(IService), typeof(Impl))
します。つまり、コンパイラがチェックできるものはすべて機能します (難読化ツールが正しく機能している場合)。
注意深く監視する必要があるのは、コンパイラがチェックできないすべてのものです。次のようなもの:
- 文字列リテラルを使用して引数の名前を指定することにより、コンストラクターの引数をオーバーライドします。
- "AppSetting" または "ConnectionString" でコンストラクター引数の名前を後置し、登録するすべての型の名前が "Controller" で終わることを期待するなど、型情報ではなく名前に基づいて型情報を使用する構成アプローチに関する規則。型を特定の名前空間に配置します。
したがって、これらの問題を注意深く監視する必要があります。検証可能な構成を作成して自分自身を保護することを忘れないでください。あなたの場合、アプリケーションの起動時にこの構成を検証します (または、アプリケーションがセルフチェックを実行できるようにコマンド ライン スイッチを追加します)。
それはすべて、DIがどのように機能するかによって異なります。クラスまたはインターフェース名 (基本クラスとマーカー インターフェースなど) に基づいて DI を実行し、それらのクラスまたはインターフェースが難読化されたライブラリにある場合、はい、DI は壊れます。難読化されていない別のライブラリ、おそらく何らかの共通またはコアがあり、そのクラスとインターフェイスが ID で使用されている場合は、使用するライブラリが難読化されていても問題ありません。難読化されていない外部ライブラリの名前は変更されません。
例を確認するには、難読化されたライブラリまたは exe を逆コンパイラで調べてください。.NET などの外部ライブラリへの参照は難読化されておらず、また難読化できないことがわかります。