ASP.NET MVC では大量の MEF を使用していますが、そのほとんどはコントローラー レベルより下のレベルにあります。これは、下位レベルのモジュールでアクセス許可のチェックとデータの検証に MEF プラグインを使用しているためです。
ただし、コントローラーに対しても、より構成可能なアプローチを使用します。ビューはもっとトリッキーですが、実際には、通常の ASP.NET MVC ビューの使用を完全に排除し、Razor ビューをデータベースのスニペットに保存しました。次に、コントローラーは実行時にテンプレート エンジンにビューを要求し、View("Viewname") などを返す代わりに ContentResult を応答にレンダリングします。
私たちの MEF プラグインはすべて、実行時にカスケード オーバーライドを実行して、特定の目的に使用する必要があるプラグイン/クラスを特定できる識別子プロパティを持っています。実証する最も簡単な例は、共通のベースを持つが、それぞれがコア機能をオーバーライドするオプションを持つ 50 以上の実装にデプロイされているアプリについて考える場合です。
したがって、「ログイン」、「ログアウト」などのメソッドを含む IUserController のようなものがあるかもしれません。
その実際の機能に加えて、"SiteId" と呼ばれるインターフェイスに読み取り専用の GUID プロパティを追加します。次に、各実装は、対象となる SiteId をハードコーディングします。コア コードの "既定" の実装では、"Guid.Empty" が返されます。
次に、MEF を呼び出して、使用する IUserController の実装を探しに行くときは、それらすべての ImportMany を List に実行し、LINQ を使用してプロパティをクエリして、使用するものを特定します。
var _currentUserController = _availableUserControllers.FirstOrDefault(
c=>c.SiteId == AppSettings.SiteId);
if(_currentUserController == null){
//There is no site-specific override
_currentUserController = _availableUserControllers.FirstOrDefault(
c=>c.SiteId == Guid.Empty);
}
コントローラーでこれを行うには、Web 上にある MEF ベースのコントローラー ファクトリの実装をいくつか調べるのが最善の策です。
しかし、私が言ったように、私たちはこれのほとんどすべてをより低いレベルで行い、モジュールまたはコントローラーにこの種のルックアップを実行させて、どのプラグインを実行するかを決定させます。