reflection - MEF 対反射

Question

私は最終的に MEF をいじり始めましたが、主な問題を解決するのは簡単ではないことがわかりました。

問題: それぞれ独自のアセンブリに存在するいくつかのカスタム アルゴリズムに依存する WCF サービスがあります。メソッドが呼び出されると、要求のデータ コントラクトの一部によって、必要なアルゴリズムが特定されます。たとえば、クラス One とクラス Two はそれぞれ NameFile() メソッドを実装し、クラス A と B はそれぞれ EncryptFile() を実装します。

サービスの WriteFile() への 1 つの呼び出しでは、Two.NameFile と A.EncryptFile を呼び出す必要がある場合があり、別の呼び出しでは One.NameFile と B.EncryptFile が必要な場合があります。

試行: MEF (私は初めてです) は、アセンブリをロードするための優れた方法のように見えましたが、これまでに見つけたものは、実行時に使用可能な契約会議のどれを決定するために多くの手順を実行する必要があるかのようですアセンブリはニーズに適合します。Plain Old Reflection は、特定のニーズが通話中にのみわかっている場合に決定してロードするためのより簡単な方法のようです。

質問 MEF は実際に他の動的読み込みシナリオにより適していますか、それとも単に私の MEF 初心者ですか?

ありがとう、

ジョン

Answer 1

MEFは実際に他の動的負荷シナリオにより適していますか、それとも私のMEFヌービズムだけですか？

さて、主な問題は、実行時に、使用したいコントラクトを満たすオプションを決定することです。

この決定は、MEF、その他のインジェクションメカニズム、またはリフレクションを使用した独自のバージョンのローリングなど、選択した内容に関係なく発生する必要があります。

ただし、MEFを使用すると、使用可能なすべてのアセンブリからすべての（またはその他の）実装[ImportMany]をインポートするのが簡単になるため、独自のバージョンをローリングするよりも簡単にする必要があります。IFileEncryptorその時点で、利用可能なリストから正しいものを決定するのはかなり簡単なはずです。

リフレクションを使用すると、特定のアセンブリから特定のタイプを取得することができます。これは、これを動的に行う目的を実際に無効にします。MEFを使用すると、新しいアセンブリを所定の場所にドロップして自動的に検出できるため、再コンパイルやコード変更なしでこのサービスを簡単に拡張できます。