2

既存の .NET アプリケーションのプラグイン解決のソリューションとして MEF を研究しています。

私が見つけたすべての例で、メイン アプリケーションは CompositionContainer のインスタンスを作成し、container.ComposeParts(this) を呼び出します。

問題は、私のアプリケーションが完全に MEF で構築されているわけではないため、オブジェクト グラフに MEF コンポーネントのない穴が開いていることです。したがって、私のオブジェクト階層は次のようになります。

アプリケーション (MEF コンテナー) -> ObjectB (MEF なし) -> ObjectA (MEF インポートが必要)

このオブジェクト階層では、アプリケーションで container.ComposeParts(this) を呼び出して、アプリケーションが ObjectB を作成し、ObjectA のインポートを満たすことを期待することはできません。

アプリケーションの起動時よりも後で ObjectA を作成できるように、CompositionContainer をグローバルに公開することは良い方法ですか?それとも、線形 MEF オブジェクト グラフをサポートするためにアプリケーション全体を再構築する必要がありますか?

4

1 に答える 1

2

CompositionContainer をグローバルに公開することをお勧めしますか?

私はそれを良い習慣とは呼びませんが、どこにでも建設のための制御原理の反転を導入することが不可能な場合、それは合理的な妥協です. 場合によっては、既存のコードベースが完全に制御できない場合や、.NET とネイティブ コード (COM コンポーネントなど) が複雑に混在している場合や、大きすぎてリファクタリングできない場合があります。

Silverlight では、XAML からのオブジェクトの構築も MEF の制御外であるため、Microsoft は基本的に同じソリューションを導入しました。デフォルトの MEF コンテナーはグローバルとしてアクセス可能であり、PartInitializer.SatisfyImports(this);.

このパターンに従うと、グローバルのすべてのコンシューマーが MEF とそれを公開するために使用されるグローバル変数に密接に結合されることに注意してください。このコードをそのまま他のアプリケーションや他の IoC コンテナーで再利用することはできません。また、単体テストも複雑になります。

于 2010-06-29T21:39:51.313 に答える