Блог

Обновить

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

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

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

Оригинальное сообщение

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

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

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

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

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

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

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

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

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

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

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

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

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

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