MEF(Managed Extensibility Framework)が、機能決定のマイルストーンに、達したのを祝して、.NET Frameworkの拡張性について、混乱した話を見ることにする。MEFは、マイクロソフトが公開した、４度目の拡張可能フレームワークである。以前と同じように、マイクロソフトは、最初の公開だ、と言っているが。
Managed Extensibility Framework, すなわちMEFは、.NET Framework用の正式の依存性注入である。文書の中で、マイクロソフトは、次のように言っている、
MEFは、実行時の拡張可能性の問題、に対する単純な解を、提供する。これまで、プラグインモデルのサポートを望む、すべてのアプリケーションは、自前のインフラをゼロから作る必要が、あった。そのようなプラグインは、得てして、アプリ特有で、複数の実装間で、再利用できなかった。
しかし、これは、真実ではない。 Spring.NETのようなサードパーティのフレームワークに加えて、マイクロソフト自身によって開発された、.NETランタイム用の拡張可能フレームワークは、少なくとも３つは、存在する。
- Unity, 一種の エンタープライズ ライブラリ Unity Application Block
- The Composite Application Library これは、WPFとSilverlightアプリ専用
- The CLR Add-In Model MAFとしても知られている
では、どれを使うべきか？ Glenn Block 氏は、以下のように述べている、
System.Addin は、バージョン毎の柔軟性、分離性、回復性に関する問題を扱うのに、素晴らしい技術です。
- System.Addin を使うと、別々のAppDomain(アプリケーション ドメイン)に異なったコンポーネントをホストでき、これらのアドインが参照する、すべて同じプロセスの中で走る、異なったバージョンのアセンブリを持つことができる。
- System.Addin は、違ったバージョンのアドインを許すので、２つのバージョンのアドインを隣同士で、走らせられる。
- System.Addin は、使用されなくなったAppDomainを自動的に、アンロードし、メモリを再利用できるように、管理している。
- System.Addin には、セキュリティインフラがあるので（アドインは、サンドボックスの中で走る）、ロードされたコンポーネントからは、アプリの他の部分にあるデータに、権限のないアクセスは、絶対にできない。
- アドインのひとつが、クラッシュしても、System.AddInのおかげで、あなたのアプリは、優雅に回復できる（これは分離性のおかげです）。
一方、MEFは、発見と組み立てのための素晴らしい技術であり、
- MEFは、深いオブジェクト階層のコンポーネントを組み立てる。
- MEFは、静的な依存性からコンポーネントを抽出する。
- MEFは、コンポーネントの遅延ロードや遅延インスタンス化ができる。
- MEFは、コンポーネントを動的に発見できるように、分類する機構や豊富なメタデータを提供する。
- MEFは、静的なタイプに限らず、様々なプログラミングモデルから、コンポーネントを組み立てることができる。
アドインモデル(System.Addin)の上に、MEFを単純に作るのではなく、こうしてもセキュリティと安定性に寄与する、分離の点で、いくつかの著しい優位性を享受できるが、MEFは、既存の技術を、ほとんどあるいは、全く考慮せずに、ゼロから作られてきたようである。
２つの技術に関する混乱を見ると、マイクロソフト内で論争があったようである。一方では、 Managed Extensibility Frameworkで拡張可能なアプリケーションを作るのようなビデオを見ているし、１１月に、プログラムマネージャのGleen Block氏は、「MEFが、拡張性を前進させる、フレームワークとしての位置にいる。」と、さえ主張している。
他方では、２００８年の６月に、Krzysztof Cwalina氏が、示した図には、はっきりと MEFは、アドインモデルと一緒に使われている。そしてプログラムマネージャのNicholas Blumhardt氏は、.NET 4の公開後に ２つのプロジェクト間の相互運用性について考えられるだろう 、と述べた。
これらのことから、アドインモデルは、大方のひとには、役立たないということである。それは、面食らうほど複雑なフレームワークで、とりかかるにも System.Addin Pipeline Builder のようなコード生成ツールが、必要である。そしてこれは、あのプロジェクトの２度目の生まれ変わりであることを、注意すべきである。保守されずに、バグも修正されないままの元々のプロジェクトから生まれたのである。
では、System.AddInの運命はいかに？ 異論を唱える者は、いないと思うが、LINQ to SQLのように静かに葬られるだろう。