Подобная плагину архитектура в.NET
Я пытаюсь реализовать плагин как приложение. Я знаю, что уже существует несколько решений там, но это просто будет подтверждением концепции, ничто больше. Идея состояла бы в том, чтобы подать главное приложение заявки, почти невыразительное по умолчанию и затем сообщать плагинам друг о друге, имение их имеет, реализуют все необходимые опции.
Возникают несколько проблем:
- Я хочу, чтобы плагины во времени выполнения знали друг о друге через мое приложение. Это не означало бы, что в разовом кодом они не могли сослаться на блоки другого плагина, таким образом, они могли использовать его интерфейсы, только та инициализация сменной функции должна всегда быть через мое главное приложение. Например: если у меня есть оба загруженные X и Y плагинов, и Y хочет использовать функции X, он должен "зарегистрировать" свой интерес хотя мое приложение для использования его функций. У меня должен был бы быть своего рода "словарь" в моем приложении, где я храню все загруженные плагины. После регистрации для интереса к моему приложению плагин Y получил бы ссылку на X, таким образом, это могло использовать его. Действительно ли это - хороший подход?
- При кодировании плагина Y, который использует X, я должен был бы сослаться на блок X, таким образом, я могу программировать против его интерфейса. Это имеет проблему управления версиями. Что, если я кодирую свой плагин Y против устаревшей версии плагина X? Я должен всегда использовать "центральное" место, где все блоки, имея там всегда актуальные версии блоков?
Есть ли случайно какие-либо книги там, которые конкретно имеют дело с этими видами проектов для.NET?
Спасибо
править: Я думаю, что люди дрейфуют далеко от этих 2 вопросов, которые я сделал. Я могу смотреть и на MEF и на #develop, но я хотел бы получить ответы специфических особенностей на вопросы, которые я сделал.
5 ответов
Посмотрите в пространство имен System.AddIn . Это немного более низкий уровень, чем MEF, и поэтому должен дать вам возможность «реализовать сам», которую вы ищете.
Рекомендую изучить MEF . Это новый способ создания надстроек в .NET. Это рекомендуемый способ создания новых надстроек, например, для VS2010. Сам я не использовал его, но то, что я изучил, выглядит отлично. Добавляя это как ответ на уговоры других:)
Есть хорошая книга по созданию того, что вы ищете: Анализ приложения C #: внутри SharpDevelop. Вот ссылка: http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx
Приложение SharpDevelop полностью основано на плагинах, и в книге рассказывается о том, как они его создали, о подводных камнях, с которыми они столкнулись, и как они это преодолели. Книга находится в свободном доступе на сайте, или ее тоже можно купить.
Однажды я сделал это, используя этот пример. Мне понравилось, но это было пару лет назад, думаю, сейчас есть решения получше. Насколько я помню, основная идея была в том, что в вашей программе есть абстрактный класс, а ваши плагины наследуют этот класс и компилируются как DLL... или что-то подобное с использованием интерфейсов. В любом случае, этот подход отлично работал для меня. Позже я добавил наблюдателя за файловой системой, чтобы он мог загружать эти DLL-плагины во время работы программы.
По поводу двух выявленных вами конкретных проблем:
1) Я не уверен, чего вы пытаетесь достичь, но предполагаю, что вы хотите иметь ленивую инициализацию функций и, возможно, ленивую загрузку надстроек. Если это цель, то то, что вы предлагаете, может сработать. Таким образом, это могло бы работать следующим образом:
- Плагин Y предоставляет список функций, которые ему необходимо использовать (это может быть сделано, например, через конкретную реализацию интерфейса или через XML-манифест).
- Надстройка X реализует API, который позволяет инициализировать функцию с помощью такого метода, как Initialize (featureId) .
- Хост-приложение получает список функций, требуемый Y, загружает / инициализирует плагин X и вызывает Initialize для каждой функции.
- Хост-приложение также предоставляет метод GetFeature () , который Y может использовать для получения ссылки на объект «особенность», который будет реализован в X.
Однако, если плагин Y имеет прямой доступ к X API, я думаю, нет необходимости иметь всю эту инфраструктуру для регистрации функций. Y может просто получить доступ к функциям X, напрямую используя X API, а Y позаботится о ленивой инициализации каждой функции при необходимости. Например, Y может просто вызвать SomeXFeature.DoSomething (), и реализация этого класса инициализирует функцию при первом ее использовании.
2) Если API сборки изменится, любая сборка, зависящая от нее, может сломаться. Плагины - это просто сборки, которые зависят от других сборок, поэтому они также сломаются. Вот несколько советов, которые помогут решить эту проблему.
- Назначьте номер версии каждому плагину. Это могла быть просто версия сборки.
- При загрузке подключаемого модуля убедитесь, что все зависимости могут быть должным образом удовлетворены (то есть все подключаемые модули, от которых он зависит, должны присутствовать и иметь требуемую версию). Отказаться от загрузки плагина, если зависимости не могут быть удовлетворены.
- Реализовать инструмент управления плагинами, который будет использоваться для всех операций установки / удаления плагинов.Менеджер может проверять зависимости и сообщать об ошибках при попытке установить плагины с неудовлетворенными зависимостями или при попытке удалить плагин, от которого зависят другие плагины.
Подобные решения используются фреймворком Mono.Addins . В Mono.Addins каждая надстройка имеет номер версии и список надстроек / версий, от которых она зависит. При загрузке надстройки механизм надстройки обеспечивает загрузку всех зависимых надстроек с правильными версиями. Он также предоставляет API и инструмент командной строки для управления установкой надстроек.