Есть MEF. Есть Assembly.Load+руки. Есть сторонние библиотеки.
Что выбрать?
Задача простая: есть группа внешних сервисов со схожим функционалом, но с разным типом доступа. Конкретно, сервисы браузерных закладок. Фуниционал: создать группу ссылок, добавить ссылку у группу, посмотреть список групп, список ссылок, детали ссылки, сохранить копию страницы и пр. А вот реализация разная: в одном JSON, в другом XML, в третьем бинарный протокол и т.д.
Хотелось бы для каждого сервиса создать свою .dll-ину с реализацией протокола и общим интерфейсом. И чтобы при добавлении очередного сервиса, не нужно было пересобирать проект -- просто закинуть .dll в папку plugins.
Сейчас рассматриваю варианты. Если кто может посоветовать -- милости прошу.
. В общем случае я бы начал со второго варианта + MEF или своя реализация IServiceProvider. Этот вариант легко допиливается в любую из сторон. Если пути для плагинов известны заранее, трюка со вторым appdomain не потребуется.
Здравствуйте, Shmj, Вы писали:
S>Задача простая: есть группа внешних сервисов со схожим функционалом, но с разным типом доступа. Конкретно, сервисы браузерных закладок.
Не постесняюсь выглядеть глупо, мне ваша мешанина вообще непонятна — сервисы, закладки, протоколы... Вы уверены, что не берёте молоток ради молотка? Может, тут хватит простой отвёртки?
Из прозвучавшего уловил только то, что городить плагины вы собираетесь тупо из-за разницы в форматах сериализации — А ОНО ТОГО СТОИТ?? Откуда у вас вообще такой зоопарк форматов? Возможно, имеет смысл описать задачу функционально, а не подкидывать нам ваши надуманные решения — тогда и ответы будут более конструктивные.
Здравствуйте, btn1, Вы писали:
B>Не постесняюсь выглядеть глупо, мне ваша мешанина вообще непонятна — сервисы, закладки, протоколы... Вы уверены, что не берёте молоток ради молотка? Может, тут хватит простой отвёртки?
Нужно чтобы эти обертки можно было подключать без переустановки программы.
B>Из прозвучавшего уловил только то, что городить плагины вы собираетесь тупо из-за разницы в форматах сериализации — А ОНО ТОГО СТОИТ?? Откуда у вас вообще такой зоопарк форматов?
Зоопарк форматов из за отсутствия единого стандарта. Каждый сервис клепает по своему усмотрению.
Re[3]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, btn1, Вы писали:
B>Загоните их все в одну ДЛЛ и поставляйте вместе с прогой.
Тогда если добавится новый сервис -- пользователю нужно будет скачивать новую версию программы. А хотелось бы, чтобы просто получил с сайта список доступных плагинов и выбрал птичкой какой добавить.
Re[2]: Как лучше сделать плагинную систему сегодня?
Про MEF там ничего нет.
S>В общем случае я бы начал со второго варианта + MEF
А зачем для MEF второй вариант? Он же самодостаточен.
S>или своя реализация IServiceProvider. Этот вариант легко допиливается в любую из сторон. Если пути для плагинов известны заранее, трюка со вторым appdomain не потребуется.
IServiceProvider имеет ли какую встроенную поддержку со стороны .Net? Или он, по сути, ничем не отличается от своего такого же интерфейса с методом типа object GetService(Type serviceType)?
Re[2]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, Shmj, Вы писали:
S>Про MEF там ничего нет.
А про него ничего и не надо расписывать, он прикручивается поверх почти любой схемы. Или загружаем сборки сами, или собираем источники в AggregateCatalog и всё.
S>>В общем случае я бы начал со второго варианта + MEF S>А зачем для MEF второй вариант? Он же самодостаточен.
Потому что этот способ универсален: можно просто загружать ч/з Assembly.Load(), можно отдать на откуп MEF, можно избавиться от любого из способов и при этом не ломать совместимость с плагинами.
S>>или своя реализация IServiceProvider. S>IServiceProvider имеет ли какую встроенную поддержку со стороны .Net? Или он, по сути, ничем не отличается от своего такого же интерфейса с методом типа object GetService(Type serviceType)?
Ничем. Просто стандартный способ для ситуации "надо же с чего-то начать"
Re[2]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, AndrewVK, Вы писали:
AVK>ИМХО MEF жутко overdesigned. По моему проще написать самому под конкретную задачу.
На мой поверхностный взгляд — нет, особенно если не лезть к нему внутрь. Ещё бы допилили разруливание зависимостей по naming convention как в asp.net vnext, совсем интересно было бы.
Другое дело, что MEF стоит применять только если не хватает стандартной комбинации IServiceProvider + хелперы для получения стандартных сервисов, иначе оверкилл получается.
Re[3]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, AndrewVK, Вы писали:
AVK>В каком смысле поподробнее? В MEF куча наворотов, полезность которых весьма спорна.
Она не то чтоб спорна, просто mef под большие проекты заточен. Он же продукт догфудинга, половина функционала в редакторе студии через mef прикручена.
Re[5]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, Shmj, Вы писали:
S>Тогда если добавится новый сервис -- пользователю нужно будет скачивать новую версию программы. А хотелось бы, чтобы просто получил с сайта список доступных плагинов и выбрал птичкой какой добавить.
Это ему точно нужно?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>>Она не то чтоб спорна, просто mef под большие проекты заточен. AVK>Overdesign вижу, заточку под большие проекты — не особо.
Да ладно, где там в mef 2 (он же lightweight mef) овердизайн?
Про применимость обоих версий кратко можно глянуть вот тут. А вообще в MEF с документацией фигово, даже rx получше выглядит.
Re[5]: Как лучше сделать плагинную систему сегодня?
Здравствуйте, Shmj, Вы писали:
B>>Загоните их все в одну ДЛЛ и поставляйте вместе с прогой. S>Тогда если добавится новый сервис -- пользователю нужно будет скачивать новую версию программы. А хотелось бы, чтобы просто получил с сайта список доступных плагинов и выбрал птичкой какой добавить.
А! Понял. То есть если "птичкой" — то ничего скачивать не надо, а ДЛЛ-ка — её тащить надо!
Re[6]: Как лучше сделать плагинную систему сегодня?