Managed Extensibility Frameworkをどのように使用していますか？

MEFで約2週間働いています。MEFの目的について考え始め、MEFの使用方法を調査し、最後に3つのモジュールでホストを実装しました。契約が把握しやすく、モジュールの管理も容易です。

MEFは非常に実用的ですが、どの程度まで利用できるのでしょうか。つまり、誰もが拡張性のために既存のアプリケーションを書き直すのでしょうか？

はい、それは聞こえ、そしてめちゃくちゃ非現実的です。修辞的に言えば：

• MEFはプログラミングの現在の傾向にどのように影響していますか？

• MEFを使用する機会を探し始めましたか？

• 拡張性の恩恵を受ける可能性がある既存のアプリの大幅な書き直しを計画し始めましたか？

そうは言っても、私の質問は次のとおり
です。拡張性を備えた新しいプロジェクトをいつ計画すべきかをどのように知ることができますか？
拡張性のために既存のプロジェクトを書き直す必要があるかどうかはどうすればわかりますか？

MEFを使用している人はいますか？

MEFを使用している人はいますか？

私はMVVMパターンを使用してSilverlightプロジェクトに取り組んでいます。インターフェイスと手動の依存性注入（必要に応じてコンストラクターまたはプロパティ注入のいずれか）を介して、必要に応じてすべてのVMを一緒に配線することから始めました。面倒になり始め、MEFを基本的に依存関係注入フレームワークとして使用し始め、ビューモデル全体で使用される特定のサービスをエクスポートし、それらを必要とするビューモデルにインポートしました。完全に動作し、コードはほとんどありません。

はい、MEFは依存関係の注入を目的としていないため、実際の依存関係の注入フレームワークははるかに優れていると言う純粋主義者がいます。ただし、MEFは.NETに組み込まれており、これは大きなプラスであり、私たちのニーズを満たすには十分でした。

拡張性を備えた新しいプロジェクトをいつ計画すべきかを知るにはどうすればよいですか？拡張性のために既存のプロジェクトを書き直す必要があるかどうかはどうすればわかりますか？

IMO、常に懸念事項を適切に分離し、さまざまなモジュールが独立して変更できるようにインターフェイスを使用する必要があります。これを正しく行うと、拡張性が必要になったときにMEFを簡単に追加できます。ただし、拡張性の要件がないプロジェクトを開始して、念のためMEFを配置することはしません。必要になるのを待ちます。既存のプロジェクトの場合、必要に応じて、MEFを使用するか、代替ソリューションを使用するか、何もしないようにプロジェクトを再配線する作業を評価し、どちらが成功するかを確認します。

人々が犯す間違い、それは、MEFが拡張性のためだけに実用的であると想定しているため、命名（Managed Extensibility Framework）が原因だと思います。MEFは、拡張性、発見、およびメタデータという3つの重要事項に実際に対応しています。最後の2つは、単一のプラグインや拡張機能が表示されないアプリケーションでも非常に強力です。

これは、IOCコンテナーとしての発見の力について私が書いた記事です。http： //www.informit.com/articles/article.aspx？p = 1635818

MEFは、Silverlightでのモジュラーアプリケーションの構築と保守をより速く、より簡単にするため、ほとんどのエンタープライズラインビジネスアプリケーションで使用しています。

現在、Repositoryパターンを組み込んだいくつかのプロジェクトでMEFを使用しています。

1つは単体テスト中にさまざまなリポジトリタイプを使用し、もう1つはローカル（DBに対して直接）、リモート（WCF）およびテストリポジトリを使用しています。

どちらのプロジェクトも、コードまたは構成を介してリポジトリタイプを変更でき、MEFメタデータ/レイジータイプに基づいています。

これまでのところ、両方のプロジェクトは信じられないほどうまく実行されています。