21

Microsoft の Managed Extensibility Framework (MEF) で多くの作業をした人はいますか? すべての人にすべてのものを提供しようとしているように聞こえますが、それはアドイン マネージャーです。ダックタイピングです！肯定的か否定的かを問わず、誰かがそれを経験したことがあるかどうか疑問に思っています。

現在、次の大きなプロジェクトでは MvcContrib という汎用 IoC 実装を使用することを計画しています。MEF をミックスに投入する必要がありますか?

4

9 に答える 9

33

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

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

将来、プラットフォームを拡張したい場合、bin フォルダーに dll をドロップすれば完了です。MEF 対応アプリが新しい拡張機能で点灯します。それがMEFのビジョンです。

于 2008-09-19T02:02:31.497 に答える
8

この投稿は、Managed Extensibility FrameworkPreview2について言及しています。

そこで、MEFを実行して、以下に示す簡単な「HelloWorld」を作成しました。飛び込んで理解するのはとても簡単だったと言わざるを得ません。カタログシステムは素晴らしく、MEF自体を非常に簡単に拡張できます。アドインアセンブリのディレクトリをポイントして、残りを処理するのは簡単です。MEFの伝統であるalaPrismは確かに透けて見えますが、両方のフレームワークが構成に関するものであることを考えると、そうでない場合は奇妙だと思います。

私のクローに最もこだわるのは、_container.Compose（）の「魔法」だと思います。HelloMEFクラスを見ると、greetingsフィールドがどのコードによっても初期化されていないことがわかります。これは面白いと感じます。私は、IoCコンテナーが機能する方法を好むと思います。この方法では、コンテナーにオブジェクトを作成するように明示的に要求します。ある種の「何もない」または「空の」汎用初期化子が適切であるのではないかと思います。すなわち

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

これは、コンテナ構成コードが実行されて実際の「何か」で満たされるまで、少なくともオブジェクトを「何か」で満たします。わかりません。これは、私がいつも嫌っていたVisualBasicのEmptyまたはNothingキーワードを少し叩きます。他の誰かがこれについて何か考えを持っているなら、私はそれらを聞きたいです。多分それは私が乗り越える必要があるものです。大きな太い[インポート]属性が付いているので、完全な謎などではありません。

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

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

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

最後に、アドインDLLがどの程度信頼されているか、およびMEFが部分的な信頼環境でどのように動作するか（または動作するかどうか）について心配しています。MEFを使用するアプリケーションには完全な信頼が必要だと思います。アドインを独自のAppDomainにロードすることも賢明かもしれません。System.AddInを少し叩くのは知っていますが、ユーザーアドインとシステムアドインを非常に明確に分離できます。

わかりました-十分な発砲。これがMEFとC＃のHelloWorldです。楽しみ！

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();
        }
    }
}
于 2008-09-11T23:14:40.943 に答える
4

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

于 2008-09-19T02:07:07.867 に答える
4

ダックタイピングは、現在ドロップされていますが、V1 では出荷されません。将来のリリースでは、ダック タイピング メカニズムに接続できるプラグ可能なアダプター メカニズムに置き換えます。ダック タイピングを調べた理由は、バージョン管理のシナリオに対処するためです。Duck Typing を使用すると、輸出業者と輸入業者の間で共有されている参照を削除できるため、契約の複数のバージョンを共存させることができます。

于 2008-09-19T02:09:00.700 に答える
2

Andy、Glenn Block は、MSDN MEF フォーラムのこのスレッドで、次のような人々の (自然な) 質問の多くに答えていると思います。

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

ある程度、上記の Artem の回答は、MEF の背後にある主な意図、つまり構成ではなく拡張性に関連して正しいものです。主に構成に関心がある場合は、他の通常の IoC 容疑者のいずれかを使用してください。一方、主に拡張性に関心がある場合は、カタログ、パーツ、メタデータのタグ付け、ダック タイピング、および遅延読み込みの導入により、いくつかの興味深い可能性が生まれます。また、Krzysztof Cwalina は、MEF と System.Addins が互いにどのように関係しているかを説明しています。

于 2008-09-12T00:20:51.440 に答える
2

Ayende はここにもかなり良い記事を書いています: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

于 2008-09-27T15:11:40.170 に答える
1

.NET 4.0 フレームワークの「システム」名前空間からハングアップすることを考えると、それほど間違っていないと思います。MEF がどのように進化し、Hamilton Verissimo (Castle) が MEF の方向性にどのような影響を与えるかを見るのは興味深いことです。

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

于 2008-09-11T19:17:45.520 に答える
1

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

于 2008-09-03T22:01:14.480 に答える
0

この投稿とコメントでこれに関するより詳細な議論

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

于 2008-09-22T07:20:54.427 に答える