MEF = может испытать разочарование?

ОБНОВЛЕНИЕ

Поскольку я попытался получить MEF, работающий всюду по моему приложению, я сталкиваюсь больше с большим количеством мест, где я просто не добираюсь, почему это автоматически не создает мою библиотеку, когда я ожидаю это к. Я думаю, что все это возвращается к тому, что Reed говорил о необходимости в MEF для создания всего. Таким образом, прямо сейчас у меня есть класс средства чтения XML, который должен использовать мой CandySettings, но даже при том, что его свойство ICandySettings имеет [Импорт] атрибут, это не становится импортированным. Сначала я узнал, что [Импорт] не работает над помехами, таким образом, я изменил это. Но после этого это все еще не работало. Я думаю, что это - потому что я вручную создаю объект средства чтения XML, и что MEF хочет, чтобы я сделал, вместо этого должен [Импортировать] средство чтения XML..., что означает, что у меня теперь должен быть интерфейс для этого также.

Это почти похоже на использование МОК (или для MEF, по крайней мере), это - бескомпромиссное дело. Вы не можете только произвольно использовать его тут и там, потому что в конечном счете безотносительно класса Вы хотите ввести свойства в также потребности, которые будут созданы MEF.

Исправьте меня, если я неправ!


Исходное сообщение

Ну, дело не в этом плохо все же.:) Но у меня действительно есть вопросы после того, как Reed указал на меня на MEF как потенциальная альтернатива МОК (и до сих пор это действительно выглядит довольно хорошим).

Рассмотрите следующую модель: сопроводительный текст http://bit.ly/9W0sHt

Как Вы видите, у меня есть Приложение и эти Плагины использования приложения (возгласы, пропустил ту ассоциацию!). И Приложение и Плагины требуют использования объекта типа CandySettings, который найден в еще одном блоке.

Я сначала пытался использовать метод ComposeParts в MEF, но единственный способ, которым я мог заставить это работать, состоял в том, чтобы сделать что-то вроде этого в сменном коде.

var container = new CompositionContainer();
container.ComposeParts(this, new CandySettings());

Но это не имеет никакого смысла, потому что, почему я хотел бы создать экземпляр CandySettings в плагине? Это должно быть в Приложении. Но если я поместил его в код Приложения, затем Плагин волшебно не выясняет, как достигнуть ICandySettings, даже при том, что я использую [Импорт] в плагине и [Экспорт] в CandySettings. РЕДАКТИРОВАНИЕ (вероятно, потому что я должен называть ComposeParts () из Приложения и затем передавать его плагин?)

Путем я сделал это должно было использовать DirectoryCatalog MEF, потому что это позволяет плагин при построении, чтобы просканировать все блоки в текущей папке и автоволшебно импортировать все, что отмечено с [Импорт] атрибут. Таким образом, это похоже на это, и потенциально в каждом плагине:

var catalog = new DirectoryCatalog(".");
var container = new CompositionContainer(catalog);
container.ComposeParts(this);

Это полностью работает отлично, но я не могу не думать, что это не то, как MEF был предназначен, чтобы использоваться?

8
задан alexandrul 19 May 2010 в 09:19
поделиться

1 ответ

"Уловка" здесь в том, что вы хотите, чтобы MEF создавал ваши плагины за вас.

Вы сделаете это так, чтобы ваше приложение составило само себя с указанными типами плагинов:

class PluginRepository
{
    [ImportMany(typeof(IPlugin))]
    IEnumerable<IPlugin> Plugins { get; set; }
}

Если вы сделаете это и настроите MEF Compose для вашего класса «репозитория», MEF будет построить объекты. Затем он автоматически скомпонует их по мере их создания, поэтому ICandySettings будет скомпонован без какого-либо вмешательства за вас.

Вам нужно вручную «скомпоновать» объект только в том случае, если MEF не создает его за вас.

8
ответ дан 5 December 2019 в 20:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: