MEF = может испытывать разочарование? - PullRequest
8 голосов
/ 16 апреля 2010

UPDATE

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

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

Пожалуйста, поправьте меня, если я ошибаюсь!


Оригинальный пост

Ну, это еще не ЭТО плохо. :) Но у меня есть вопросы после того, как Рид указал мне на MEF как на потенциальную альтернативу IoC (и пока это выглядит довольно неплохо).

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

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

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

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

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

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

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

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

1 Ответ

8 голосов
/ 16 апреля 2010

«Хитрость» в том, что вы хотите, чтобы MEF создал ваши плагины для вас.

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

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

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

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

...