Куда подойдет Managed Extensibility Framework для .NET?

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

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

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

Этот пост относится к предварительной версии Managed Extensibility Framework Preview 2.

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

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

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

Это, по крайней мере, заполняет объект «чем-то» до тех пор, пока не запустится код композиции контейнера, чтобы заполнить его настоящим «чем-то». Я не знаю - это немного попахивает ключевыми словами Visual Basic Empty или Nothing, которые мне всегда не нравились. Если у кого-то еще есть какие-то мысли по этому поводу, я бы хотел их услышать. Может, мне просто нужно смириться с этим. Он отмечен большим жирным атрибутом [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();
        }
    }
}

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

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

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

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

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

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

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

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

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

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

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