Comments 36
UFO landed and left these words here
это вполне осуществимо, если будет материал, можно будет попробовать опубликовать
Отлично пишите =) С удовольствием почитаю и далее. Жалко вашу прошлую книгу купить не удалось из-за того, что не доставляют в Грузию российские магазины =(
Оотлично! Очень понравилось спасибо! Приятный стиль изложения, и как про меня написано — сам придумывал велосипед для использования плагинов, используя рефлексию и бубен. Было бы здорово почитать еще, пишите!
Спасибо, порадовали! :) Если что, готов помогать в переводе, тема MEF мне знакома.
это не перевод, спасибо за предложение, занес вас в список :-) если что — обращусь
Есть много статей на английском. Если что, могу помочь с архитектурой MEF. Т.е. Как это все работает изнутри.
Когда я был маленький и глупый ещё не знал про рефлексию и ООП, но сделать плагины уже хотелось — меня всегда интересовало, откуда компилятор узнает про тип FirstPlugin, если он вынесен в плагин и при компиляции его просто нет?
А причем здесь рефлексия? Насколько я понимаю, просто сборка с плагином статически подключена к проекту. Или я ошибаюсь?
внутри используется рефлексия, конечно, для поиска типов помеченных атрибутами и прочих дел
Это само собой. Вопрос был про то, откуда компилятор знает о FirstPlugin?
ну он же лежит в том же проекте. плюс инстанцируется нами руками.
во второй главе будет более полезный и наглядный пример плагином который лежит в другой сборке
Компилятор при сборке проекта не должен знать про типы его плагинов кроме общего интерфейса IPlugin, я считаю.
На мой взгляд, пример не очень удачный, поскольку экземпляр FirstPlugin создаётся в том же объекте, в котором используется. Это можно было просто присвоение написать: Plugin = new FirstPlugin(). А чтобы заменить FirstPlugin на SecondPlugin нужно изменять класс HomeController. Т.е просто не видно использования того механизма, ради котороно это всё, собственно, и нужно :o)
для первой главы и введения, пример подходящий
про внешние плагины нельзя рассказать без рассказа про каталоги в MEF
собственно, во второй главе про это речь и пойдет, там будут и внешние плагины с более сложным примером :-)
Хотел написать то же, что и Ordos.
Ждём продолжения.
Лишь однажды пользовался мефом и он понравился именно стандартизацией разработки.
Однако, автор этого текста настоятельно рекомендует указывать контракты всякий раз, как вы определяете импортируемые и экспортируемые части. Такое определение поможет вам быстрее понимать текст кода в дальнейшем.

А с другой стороны, это может привести к проблемам при изменении типа свойства без соответствующего изменения определения атрибута
экспортируемые части все равно помечены контрактом, без их изменения работать архитектура не будет. трудно представить, что разработчик поменял атрибуты у экспорта и не поменял у импорта

впрочем, это лишь рекомендация, если есть желание можно опускать контракт при импорте, правда не всегда
Думаю, следует добавить, что для начала надо добавить в References приложения сборку System.ComponentModel.Composition =)
именно, я в твиттере задал вопрос, найдет ли кто-нибудь то, что я пропустил? и вот нашел, спасибо за внимательность :-)
такой версии нет, MEF местами использует лямбды и другие фишки из 3.5
в принципе, наверняка, можно портировать, это же опенсорс, но это должен сделать тот кому это надо

есть альтернатива, которая, возможно подойдет
Mono.Addins

monoaddins.codeplex.com/
Только сегодня на работе обсуждали перевод одного из модулей с 2.0 на 3.5, вроде граблей быть не должно.
Если не секрет, а у вас с чем связано то, что вы не переходите на 3.5?
У нас десктопный продукт — не хочется просить пользователей качать 3.5. Мы считаем, что у многих уже есть .NET 2 и, исходя из этого, используем его. Но более-менее адекватных сравнений не делали, на сколько я знаю. Если знаете, скажите.
Еще не переходят те, для кого критична поддержка Windows 2000
Пример в ComposeParts() крайне неудачный и совсем не то, что должно фигурировать в первой статье.

<code>
Only those users with full accounts are able to leave comments. Log in, please.