PartAlex

Окей, я мысль понял. Снимаю шляпу и посыпаю голову пеплом.

Data Entities у нас как правило представляют собой сущности, отражающие структуру хранилища. Да, абстракция от конкретной субд ложится скорее на интерфейс дата провайдеров.

Да. Data Access Layer — более правильная расшифровка того, о чём я говорю.

На выходе у него Data Entities.

Который абстрагирует от конкретной СУБД.

Под DAL выше имелся ввиду Data Abstraction Layer так-то.

Я об этом же.

С чего бы вдруг DAL должен знать о каких-то деталях BLL?

*в которой

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

В заголовке Opera Mobile :) Жду печенья :)

Срыв покровов.

Объясняю:

…
VS 8 == VS 2005
VS 9 == VS 2008
VS 10 == VS 2010
VS 11 == VS 2012
…

Всегда ваш,
Кэп.

3. Отличается тем, что много более урезан по сравнению даже с Silverlight.

Выше в каментах я уже писал о том, что это два разных подхода. Тут вопросов нет.
По личному опыту — случаев, когда необходимо использовать System.Addin — мало. Геморроя связанного со спецификой AppDomain — много, но иногда он оправдан.

Посему… начав писать демо для второй статьи, и посчитав впоследствии это всё неинтересным, я забил на неё…

Не стоит. Используйте MEF и будет счастье. System.Addin, я надеюсь, уйдёт в анналы истории и больше никогда оттуда не вернётся :)

в блоге команды CLR Addins Джесс Каплан, если мне память не изменяет, писал статейку, в которой делался вывод о том, что оверхед не такой уж и страшный при использовании System.Addin. In-domain, Cross-domain и Cross-process сценарии сравнивались.

Опыт показывает, что возможно всё.
Вопрос только в том, сколько времени это займёт :)

System.Addin разрабатывался для несколько других сценариев…

Если не секрет, какими возможностями обладает «решение в две строчки»? :)

Не смотря на то, что MEF и System.Addin вроде бы как служат для одной цели — они разные. Просто разные. У каждого из них есть свои фишки, которых нет у другого…

На вкус и цвет, опять же… лично я сомневаюсь в эффективности разработки с одним только рефлектором под руками и без MSDN…

На самом деле публикация нескольких статей по MEF была у меня в планах после завершения цикла статей про System.Addin :)

У каждого свой стиль ;)

Копание исходников рефлектором — крайность, к которой лично я прибегаю только в том случае, если уже пересмотрена вся документация, а проблема всё ещё не решена… либо когда адекватной доки просто нет.

Я более, чем уверен, что и вы не смотрите реализацию каждого класса рефлектором.
В MSDN есть косяки… но на фоне общего количества информации — эти косяки занимают ничтожно мало места :)

А ещё можно просто обратиться к документации и обойтись без копания исходников :)

Если вопрос стоит так, что стоит использовать System.Addin или писать тоже самое, но руками, то тут выбор явно следует сделать в пользу первого. Хотя бы из соображений экономии времени :)

Именно так :)

Ну «представление» — это мой вольный перевод слова view :)

Это либо интерфейсы, либо какой-либо наследуемый(возможно абстрактный) класс.
Так, например, Хост видит Addin только через Хост-представление… хотя фактически работает с объектом адаптером, который перенаправляет запросы к контракту, который в свою очереднь перенаправляет их дальше на сторону расширения.

Следующая статья многое прояснит.

Не хотелось, чтобы статья получилась длинной… следующая будет как раз демонстрировать пример :)

Блин… промахнулся с ответом… извиняйте :) Я тут новичок) Не привык ещё)

Стоп :) Я только сейчас понял, что Вы говорите о SharpDevelop :)
Статья совсем не о #develop :) Она о новом полезном инструменте для разработчиков, который включён в библиотеку .NET 3.5 ;)

Почему же не предполагает?) Хост-приложение может быть обычным Stand-alone приложением :) Может так же по-старому цеплять плагины через Reflection или вообще работать без всяких расширений :)

Сорри… поправил… сейчас вроде как должно быть всё хорошо.