ほとんどのアプリケーションは、依存性注入(dependency injection)フレームワークが完全に意味があるとはいえない。通常は、最初から最後まで手動ですべての依存性をつなげてても全く問題はない。しかしASP.NET MVCの場合は、実際にはひとつの起点ではない。それぞれの依存性は、サーバー、ユーザーセッション、コントローラーや個々のリクエストにスコープしている。多くの競合ライフサイクルにおいてDIフレームワークは、不要な問題から目をそらして、本質的な組織ツールに移行している。
重要な利用局面としてこれを見ると、MEF 2には、MVCの依存性を扱うための機能が含まれている。すべては、規約ベースアプローチを使って完結しており、追加の構成ファイルは必要ない。
MEF 2を使う場合、Partsと呼ばれる新しいフォルダが必要になる。ここにはコントローラがデータアクセス、ロギング、他のサイトやWebサービスとの通信などで必要になるクラスを保持しておく。コントローラがどのパーツを必要とするかを指定するのは、単純にコントローラのコンストラクタにこれらのリストを渡すだけである。指定したパーツが他のパーツをリクエストしたときには、同じことが行われる。
デフォルトでパーツは、単一リクエストに対するライフタイムを持ち、各パーツでひとつだけ作成されるため、いくつのコントローラや他のパーツが必要になったかは問題ではない。一度リクエストが完了すると、それが必要としたあらゆるパーツのDisposeが呼ばれる。もしパーツのライフサイクルをアプリケーションと同じにする場合、ApplicationShared属性が適用される。詳細な登録オプションが提供されているが、属性のタグ付けは、ほとんどの利用局面で処理する必要がある。
他のアセンブリからのパーツは、Application_StartでCompositionProvider.AddPartsAssembly関数を使うことで、含めることができる。すべてのパーツの名前空間に“Parts”識別子が含まれている必要があることに注意して欲しい。BCLチームは次のように記述する。
すべてのパーツにParts名前空間を使うことは少し過剰に見えるが、すべてのクラスがパーツであるわけではないことを思い出させてくれます。パーツは、アプリケーションを作りあげる‘粗粒’のかたまりです。重要な機能を持つアセンブリは、たいてい、アセンブリの中のパーツが使うか、パーツ自身は使わない大量の補助クラスを持ちます。
モデルバインダーを表すパーツは、ModelBinderExport属性と、それが適用されるモデルの型でタグ付けする必要がある。
Actionフィルターはまた、コンポジションに参加することができる。MEFコンポジションプロバイダによって作成することはできないが、MEFによってフィルターされたプロパティを持つことができる。Import属性でMEFで管理されたプロパティとタグ付けすることができる。
ASP.NET MVCとMEF 2のサンプルは、CodePlexで提供されている。