.NET のマネージド拡張性フレームワークはどこですか?

StackOverflow https://stackoverflow.com/questions/42251

  •  09-06-2019
  •  | 
  •  

質問

Microsoft の Managed Extensibility Framework (MEF) をよく使った人はいますか?すべての人にあらゆるものを提供しようとしているように聞こえますが、これはアドイン マネージャーです。アヒルタイピングですよ！ポジティブかネガティブかに関わらず、このような経験をした人はいるだろうかと思います。

現在、次の大きなプロジェクトでは MvcContrib などの汎用 IoC 実装を使用することを計画しています。MEF をミックスに加えるべきでしょうか?

役に立ちましたか？

解決

私たちは MEF が万能の IoC になることを目指しているわけではありません。MEF の IoC の側面について考える最良の方法は、実装の詳細を検討することです。IoC は、解決しようとしている問題に対処する優れた方法であるため、パターンとして IoC を使用します。

MEF は拡張性に重点を置いています。MEF について考えるときは、私たちのプラットフォームを前進させるための投資であると考えてください。当社の将来の製品とプラットフォームは、拡張性を追加するための標準メカニズムとして MEF を活用する予定です。サードパーティの製品やフレームワークも、これと同じメカニズムを利用できるようになります。MEF の平均的な「ユーザー」は、MEF が使用するコンポーネントを作成しますが、アプリケーション内で MEF を直接使用することはありません。

将来、プラットフォームを拡張したいとき、bin フォルダーに dll をドロップするだけで完了することを想像してください。MEF 対応アプリが新しい拡張機能で点灯します。それがMEFのビジョンです。

他のヒント

この投稿では、Managed Extensibility Framework Preview 2 について説明します。

そこで、MEF を実行して簡単な「Hello World」を作成しました。これを以下に示します。とても理解しやすく、理解しやすかったと言わざるを得ません。カタログ システムは優れており、MEF 自体を非常に簡単に拡張できます。アドイン アセンブリのディレクトリを指定し、残りを処理させるのは簡単です。MEF の Prism の伝統は確かに表れていますが、どちらのフレームワークも構成に関するものであることを考えると、そうでないのは奇妙だと思います。

私が最も心に引っかかっているのは、_container.Compose() の「魔法」だと思います。HelloMEF クラスを調べてみると、どのコードによっても挨拶フィールドが初期化されていないことがわかりますが、これはちょっと面白いことです。私は、コンテナにオブジェクトの構築を明示的に要求する IoC コンテナの動作方法の方が好きだと思います。ある種の「Nothing」または「Empty」汎用初期化子が適しているのではないかと思います。つまり

private IGreetings greetings = CompositionServices.Empty<IGreetings>();

これにより、コンテナ合成コードが実際の「何か」で満たされるまで、少なくともオブジェクトが「何か」で満たされます。わかりません。これは、私がいつも嫌いだった Visual Basic の Empty or Nothing キーワードに少し似ています。他にこれについて何か考えがある人がいたら、聞いてみたいと思います。たぶんそれは私が乗り越えなければならないものなのかもしれない。大きく[インポート]属性が付いているので、完全な謎でも何でもありません。

オブジェクトの有効期間の制御は明らかではありませんが、エクスポートされたクラスに [CompositionOptions] 属性を追加しない限り、デフォルトではすべてがシングルトンになります。これにより、Factory または Singleton を指定できるようになります。いつかこのリストに Pooled が追加されるといいですね。

ダックタイピング機能がどのように機能するかはよくわかりません。ダックタイピングというよりは、オブジェクト作成時のメタデータ挿入に近いようです。そしてアヒルは一匹しか追加できないようです。しかし、先ほども言ったように、これらの機能がどのように機能するかはまだよくわかりません。後で戻ってきてこれを記入できれば幸いです。

DirectoryPartCatalog で読み込まれる DLL をシャドウ コピーするのが良いと思います。現時点では、MEF が DLL を取得すると、DLL はロックされます。これにより、ディレクトリ ウォッチャーを追加し、更新されたアドインをキャッチすることもできます。それはかなり甘いでしょう...

最後に、アドイン DLL がどの程度信頼されているか、部分信頼環境で MEF がどのように動作するか、または動作するかどうかが心配です。MEF を使用するアプリケーションには完全な信頼が必要だと思います。アドインを独自の AppDomain にロードすることも賢明な場合があります。これが System.AddIn に似ていることはわかっていますが、ユーザー アドインとシステム アドインを明確に分離できるようになります。

さて、おしゃべりはもう十分です。MEF と C# の Hello World は次のとおりです。楽しむ！

using System;
using System.ComponentModel.Composition;
using System.Reflection;

namespace HelloMEF
{
    public interface IGreetings
    {
        void Hello();
    }

    [Export(typeof(IGreetings))]
    public class Greetings : IGreetings
    {
        public void Hello()
        {
            Console.WriteLine("Hello world!");
        }
    }

    class HelloMEF : IDisposable
    {
        private readonly CompositionContainer _container;

        [Import(typeof(IGreetings))]
        private IGreetings greetings = null;

        public HelloMEF()
        {
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            _container = new CompositionContainer(catalog);
            var batch = new CompositionBatch();
            batch.AddPart(this);
            container.Compose(batch);

        }

        public void Run()
        {
            greetings.Hello();
        }

        public void Dispose()
        {
            _container.Dispose();
        }

        static void Main()
        {
            using (var helloMef = new HelloMEF())
                helloMef.Run();
        }
    }
}

MEF がロードする拡張機能のセキュリティに関する Andy の質問 (申し訳ありませんが、まだ十分なポイントがありません :) ) については、これに対処する場所がカタログにあります。MEF カタログは完全にプラグ可能であるため、ロードする前にアセンブリ キーなどを検証するカスタム カタログを作成できます。必要に応じて CAS を使用することもできます。私たちは、カタログを作成せずにこれを実行できるフックを提供する可能性を検討しています。ただし、現在のカタログのソースは無料で入手できます。少なくとも、誰か (おそらく私たちのチーム) がそれを実装し、CodePlex の拡張機能/貢献プロジェクトに投入するのではないかと思います。

ダック タイピングは、現在のドロップには含まれていますが、V1 では出荷されません。将来のドロップでは、ダック タイピング メカニズムに接続できるプラグイン可能なアダプター メカニズムに置き換える予定です。ダックタイピングを検討した理由は、バージョン管理のシナリオに対処するためです。Duck Typing を使用すると、エクスポータとインポータ間の共有参照を削除できるため、複数のバージョンのコントラクトを並行して使用できるようになります。

アンディ、グレン ブロックは、MSDN MEF フォーラムのこのスレッドで、次のような人々の (当然の) 質問の多くに答えていると思います。

CompositionContainer と従来の IoC コンテナの比較 .

上記の Artem の答えは、MEF の背後にある主な目的、つまり構成ではなく拡張性と比較すると、ある程度は正しいです。主に構成に興味がある場合は、他の通常の IoC 候補のいずれかを使用してください。一方、主に拡張性に関心がある場合は、カタログ、パーツ、メタデータのタグ付け、ダックタイピング、遅延読み込みの導入により、興味深い可能性が生まれます。また、クシシュトフ・ツワリナがシュートを放つ ここ MEF と System.Addins が相互にどのように関係するかを説明します。

Ayende もここで非常に優れた記事を書いています。 http://ayende.com/Blog/archive/2008/09/25/the-manized-extensibility-framework.aspx

コントロールコンテナの注入ではありません。プラグインサポートフレームワークです。

.NET 4.0 Framework の「System」名前空間からぶら下がっていることを考えると、それほど間違ったことはないと思います。MEFがどのように進化するのか、そしてハミルトン・ベリシモ（キャッスル）がMEFの方向性にどのような影響を与えるのかを見るのは興味深いことだろう。

アヒルのように鳴く場合、それは現在の IoC コンテナの群れの一部である可能性があります...

この投稿とコメントでこれについてさらに詳しく説明します

http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top