Куда бы ни попала управляемая структура расширения для .NET? - PullRequest
21 голосов
/ 03 сентября 2008

Кто-нибудь много работал с Microsoft Managed Extensibility Framework (MEF)? Похоже, что он пытается быть всем для всех - это менеджер надстроек! Это утка печатать! Мне интересно, есть ли у кого-то такой опыт, положительный или отрицательный.

В настоящее время мы планируем использовать универсальную реализацию IoC ala MvcContrib для нашего следующего большого проекта. Должны ли мы бросить MEF в смеси?

Ответы [ 9 ]

33 голосов
/ 19 сентября 2008

Мы не стремимся к тому, чтобы MEF был универсальным IoC. Лучший способ думать об аспектах IoC в MEF - это детали реализации. Мы используем IoC в качестве шаблона, потому что это отличный способ решения проблем, которые мы хотим решить.

MEF ориентирован на расширяемость. Когда вы думаете о MEF, рассматривайте это как инвестицию в продвижение нашей платформы вперед. Наши будущие продукты и платформа будут использовать MEF в качестве стандартного механизма для расширения возможностей. Сторонние продукты и платформы также смогут использовать этот же механизм. Средний «пользователь» MEF будет создавать компоненты, которые будет использовать MEF, и не будет напрямую использовать MEF в своих приложениях.

Представьте, что когда вы захотите расширить нашу платформу в будущем, вы поместите dll в папку bin, и все готово. Приложение с поддержкой MEF загорается вместе с новым расширением. Это видение MEF.

8 голосов
/ 12 сентября 2008

Этот пост относится к предварительному просмотру платформы управляемой расширяемости 2.

Итак, я пробежался по MEF и написал быстрый «Hello World», который представлен ниже. Я должен сказать, что было очень легко погрузиться и понять. Система каталогов великолепна и делает расширение MEF очень простым. Тривиально указать его на каталог сборок надстройки и позволить ему обрабатывать все остальное. Наследие MEF ala Prism, конечно, хорошо видно, но я думаю, что было бы странно, если бы это не так, учитывая, что обе структуры касаются композиции.

Я думаю, что в моем зобе больше всего проявляется "магия" _container.Compose (). Если вы заглянете в класс HelloMEF, то увидите, что поле приветствия никогда не инициализируется каким-либо кодом, что просто смешно. Я думаю, что я предпочитаю, как работают контейнеры IoC, когда вы явно просите контейнер создать объект для вас. Интересно, может быть в порядке какой-то общий инициализатор «Nothing» или «Empty». т.е.

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

Это, по крайней мере, заполняет объект «чем-то» до тех пор, пока не будет запущен код композиции контейнера, чтобы заполнить его реальным «чем-то». Я не знаю - это немного попирает ключевые слова Visual Basic «Пусто» или «Ничего», которые мне всегда не нравились. Если у кого-то еще есть мысли по этому поводу, я бы хотел их услышать. Может быть, это то, что мне просто нужно преодолеть. Он помечен большим жирным атрибутом [Import], так что это не полная тайна или что-то еще.

Контроль времени жизни объекта неочевиден, но по умолчанию все является одноэлементным, если только вы не добавите атрибут [CompositionOptions] в экспортируемый класс. Это позволяет вам указать либо Factory, либо Singleton. Было бы неплохо увидеть Pooled добавленным в этот список в какой-то момент.

Мне не совсем понятно, как работают функции утки. Это больше похоже на внедрение метаданных при создании объекта, а не на типизацию утки. И, похоже, вы можете добавить только одну дополнительную утку. Но, как я уже сказал, я пока не совсем понимаю, как эти функции работают. Надеюсь, я смогу вернуться и заполнить это позже.

Я думаю, что было бы неплохо создать теневые копии библиотек DLL, которые загружены DirectoryPartCatalog. Прямо сейчас библиотеки DLL заблокированы, как только MEF овладеет ими. Это также позволит вам добавить наблюдателя каталога и ловить обновленные надстройки. Это было бы довольно мило ...

Наконец, я беспокоюсь о том, насколько доверенными являются надстройки DLL и как, или если, MEF будет вести себя в среде с частичным доверием. Я подозреваю, что приложения, использующие MEF, потребуют полного доверия. Также может быть целесообразно загрузить надстройки в свой собственный домен приложений. Я знаю, что это немного напоминает System.AddIn, но это позволило бы очень четко разделить пользовательские надстройки и системные надстройки.

Хорошо - достаточно болтовни. Вот Hello World в MEF и C #. Наслаждайтесь!

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();
        }
    }
}
4 голосов
/ 19 сентября 2008

Утиная печать не будет доставлена ​​в V1, хотя в текущем выпадении. В будущем мы заменим его сменным механизмом адаптера, где можно было бы подключить механизм печатания утки. Причина, по которой мы посмотрели на типизацию утки, заключается в рассмотрении сценариев управления версиями. С помощью Duck Typing вы можете удалить общие ссылки между экспортерами и импортерами, что позволяет нескольким версиям контракта жить бок о бок.

4 голосов
/ 19 сентября 2008

На вопрос Энди о безопасности для расширений, которые загружает MEF (извините, у меня пока недостаточно очков :)), место для решения этой проблемы - в каталоге Каталоги MEF полностью подключаемы, поэтому вы можете написать собственный каталог, который проверяет ключи сборки и т. Д. Перед загрузкой. Вы даже можете использовать CAS, если хотите. Мы рассматриваем возможность предоставления хуков, которые позволят вам сделать это без необходимости писать каталог. Тем не менее, источник для текущих каталогов находится в свободном доступе. Я подозреваю, что минимум кто-то (возможно, в нашей команде) реализует его и добавит в проект расширения / вклада в CodePlex.

2 голосов
/ 27 сентября 2008

У Айенде тоже есть неплохая запись: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

2 голосов
/ 12 сентября 2008

Энди, я полагаю, что Гленн Блок отвечает на многие естественные вопросы, подобные этим, в этой теме на форуме MSDN MEF:

Сравнение CompositionContainer с традиционными контейнерами IoC .

В некоторой степени ответ Артема выше верен относительно основного намерения, стоящего за MEF, которое является расширяемостью, а не составом. Если вы в первую очередь интересуетесь композицией, используйте других подозреваемых в IoC. Если, с другой стороны, вас в первую очередь интересует расширяемость, то введение каталогов, деталей, тегов метаданных, типизирования утки и отложенной загрузки создает некоторые интересные возможности. Кроме того, Кшиштоф Квалина делает снимок здесь , объясняя, как MEF и System.Addins связаны друг с другом.

1 голос
/ 11 сентября 2008

Я бы сказал, учитывая, что он собирается зависнуть от пространства имен 'System' в .NET 4.0 Framework, что вы не ошибетесь слишком далеко. Будет интересно посмотреть, как развивается MEF и как Гамильтон Вериссимо (Замок) влияет на направление MEF.

Если он крякает как утка, он просто может быть частью текущей стаи контейнеров IoC ...

1 голос
/ 04 сентября 2008

Это не инъекция контрольного контейнера. Это плагин поддержки инфраструктуры.

0 голосов
/ 22 сентября 2008

Более подробное обсуждение этого в этом посте и комментариях

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

...