Куда направляется платформа расширяемости для .NET?
https://stackoverflow.com/questions/42251
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Кто-нибудь много работал с платформой управляемой расширяемости Microsoft (MEF)?Звучит так, будто он пытается быть всем для всех людей - Это менеджер надстроек!Это утиный набор текста!Мне интересно, есть ли у кого-нибудь опыт работы с этим, положительный или отрицательный.
В настоящее время мы планируем использовать универсальную реализацию IoC ala MVC contrib для нашего следующего большого проекта.Должны ли мы добавить в смесь MEF?
Решение
Мы не стремимся к тому, чтобы MEF была универсальным МОК.Лучший способ подумать об аспектах MEF, связанных с МОК, - это детали реализации.Мы используем IoC в качестве шаблона, потому что это отличный способ решения проблем, которые мы хотим решить.
MEF ориентирован на расширяемость.Когда вы думаете о MEF, рассматривайте его как инвестицию в продвижение нашей платформы.Наши будущие продукты и платформа будут использовать MEF в качестве стандартного механизма для расширения.Сторонние продукты и фреймворки также смогут использовать этот же механизм.Средний "пользователь" MEF будет создавать компоненты, которые MEF будет использовать, и не будет напрямую использовать MEF в своих приложениях.
Представьте, что вы хотите расширить нашу платформу в будущем, вы помещаете библиотеку dll в папку bin и все готово.Приложение с поддержкой MEF загорается с новым расширением.Таково видение MEF.
Другие советы
Этот пост ссылается на предварительный просмотр платформы управляемой расширяемости 2.
Итак, я просмотрел MEF и написал краткое сообщение "Привет, мир", которое представлено ниже.Я должен сказать, что погрузиться в это было совершенно легко и понять.Система каталогов великолепна и упрощает процесс расширения MEF.Тривиально указать его на каталог сборок addin и позволить ему обрабатывать все остальное.Наследие ala Prism от MEF, безусловно, просматривается, но я думаю, было бы странно, если бы этого не произошло, учитывая, что оба фреймворка связаны с композицией.
Я думаю, что больше всего мне не дает покоя "магия" _container.Compose() .Если вы заглянете в класс HelloMEF, вы увидите, что поле приветствия никогда не инициализируется каким-либо кодом, что просто кажется забавным.Я думаю, что мне больше нравится способ работы контейнеров IoC, когда вы явно просите контейнер создать объект для вас.Интересно, подойдет ли какой-нибудь "Ничего" или "Пустой" универсальный инициализатор.т. е.
private IGreetings greetings = CompositionServices.Empty<IGreetings>();
Это, по крайней мере, заполняет объект "чем-то" до тех пор, пока не будет запущен код композиции контейнера, чтобы заполнить его реальным "чем-то".Я не знаю - это немного напоминает ключевые слова Visual Basic Empty or Nothing, которые мне всегда не нравились.Если у кого-то еще есть какие-то мысли по этому поводу, я хотел бы их услышать.Может быть, это что-то, с чем мне просто нужно смириться.Он помечен большим жирным атрибутом [Import], так что не похоже, что это полная тайна или что-то в этом роде.
Управление временем жизни объекта неочевидно, но по умолчанию все является одноэлементным, если только вы не добавите атрибут [CompositionOptions] к экспортируемому классу.Это позволяет вам указать либо Factory, либо Singleton.Было бы неплохо, если бы Pooled был добавлен в этот список в какой-то момент.
Я не совсем понимаю, как работают функции duck typing.Это больше похоже на ввод метаданных при создании объекта, а не на утиный ввод.И, похоже, вы можете добавить только одну дополнительную утку.Но, как я уже сказал, я пока не совсем понимаю, как работают эти функции.Надеюсь, я смогу вернуться и заполнить это позже.
Я думаю, было бы хорошей идеей теневое копирование библиотек DLL, загружаемых DirectoryPartCatalog.Прямо сейчас библиотеки DLL блокируются, как только MEF получает доступ к ним.Это также позволило бы вам добавить средство просмотра каталогов и перехватывать обновленные дополнения.Это было бы очень мило...
Наконец, я беспокоюсь о том, насколько надежны библиотеки DLL addin и как, или если, 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:
Сравнение состава контейнера с традиционными контейнерами IoC .
В какой-то степени приведенный выше ответ Артема верен относительно основной цели, стоящей за MEF, которая заключается в расширяемости, а не в композиции.Если вас в первую очередь интересует композиция, то используйте один из других обычных вариантов IoC.С другой стороны, если вас в первую очередь интересует расширяемость, то введение каталогов, деталей, тегов метаданных, скрытого ввода и отложенной загрузки - все это открывает некоторые интересные возможности.Кроме того, Кшиштоф Квалина делает бросок здесь при объяснении того, как MEF и System.Дополнения связаны друг с другом.
У Айенде также есть довольно хорошая статья здесь: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx
Это не инъекция контрольного контейнера.Это платформа поддержки подключаемых модулей.
Я бы сказал, учитывая, что это будет зависать за пределами пространства имен "System" в .NET 4.0 Framework, что вы не могли ошибиться слишком далеко.Будет интересно посмотреть, как развивается MEF и какое влияние оказывает Гамильтон Вериссимо (Castle) на руководство MEF.
Если он крякает, как утка, это просто может быть частью текущей коллекции контейнеров IoC...
Более подробное обсуждение этого вопроса в этом посте и комментариях
http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
