Как создать гибкую архитектуру плагинов?

Обычно я использую MEF. Платформа Managed Extensibility Framework (или сокращенно MEF) упрощает создание расширяемых приложений. MEF предлагает возможности обнаружения и компоновки, которые вы можете использовать для загрузки расширений приложений.

Если вам интересно, прочтите подробнее ...

Одна из лучших архитектур подключаемых модулей, которые я видел, реализована в Eclipse. Вместо приложения с моделью подключаемого модуля все является подключаемым модулем. Само базовое приложение является фреймворком надстройки.

http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html

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

1. Один следует модели Eclipse, которая предназначена для обеспечения свободы и является открытой.
2. Другая обычно требует, чтобы плагины следовали узкому API, потому что плагин будет выполнять определенную функцию.

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

Различие тонкое, а иногда его нет... вы хотите и то, и другое для вашего приложения.

У меня нет большого опыта работы с моделью Eclipse/Opening up your App to plugins (статья в посте Kalkie замечательная). Я немного читал о том, как eclipse делает вещи, но не более того.

Блог Егге properties немного рассказывает о том, как использование паттерна свойств позволяет создавать плагины и расширяемость.

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

Много лет назад я создавал фабрики, менеджеры плагинов и конфигурационные файлы, чтобы управлять всем этим и позволять мне определять, какой плагин использовать во время выполнения.

• Сейчас я обычно просто поручаю DI framework делать большую часть этой работы.

Мне все еще приходится писать адаптеры для использования сторонних библиотек, но они обычно не так уж плохи.

Однажды я работал над проектом, который должен был быть настолько гибким, чтобы каждый заказчик мог настроить систему, и единственный хороший вариант, который мы нашли, заключался в том, чтобы отправить заказчику компилятор C #!

Если в спецификации используются такие слова, как:

• Гибкий
• Подключаемый модуль
• Настраиваемый

Задайте множество вопросов о том, как вы будете поддерживать систему (и как будет взиматься плата за поддержку, поскольку каждый клиент будет думать, что его случай является нормальным и не должен нуждаться в каких-либо дополнительных модулях.), как по моему опыту

Поддержка клиентов (или сотрудников службы поддержки fount-line), пишущих {{1} } Плагины намного сложнее, чем Architecture

По моему опыту, два лучших способа создания гибкой архитектуры плагинов - это языки сценариев и библиотеки. Эти две концепции, на мой взгляд, ортогональны; их можно смешивать в любой пропорции, как в функциональном и объектно-ориентированном программировании, но они обнаруживают свои самые сильные стороны, когда они уравновешены. Библиотека обычно отвечает за выполнение определенного интерфейса с динамическими функциями, тогда как сценарии имеют тенденцию подчеркивать функциональность с динамическим интерфейсом.

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

Для того, чтобы это работало, система сценариев должна иметь довольно надежный API с привязками к данным приложения, логике и графическому интерфейсу, а также базовые функции импорта и выполнения кода из библиотек. Кроме того, обычно требуется, чтобы сценарии были безопасными в том смысле, что приложение могло корректно восстанавливаться после плохо написанного сценария.Использование системы сценариев в качестве уровня косвенного обращения означает, что приложение может более легко отсоединиться в случае Something Bad ™.

Способы упаковки плагинов во многом зависят от личных предпочтений, но вы никогда не ошибетесь, выбрав сжатый архив с простым интерфейсом, скажем, PluginName.ext в корневом каталоге.

Я думаю, вам нужно сначала ответить на вопрос: "Какие компоненты должны быть плагинами?". Вы хотите свести это число к абсолютному минимуму, иначе количество комбинаций, которые вы должны протестировать, возрастет. Постарайтесь отделить ваш основной продукт (который не должен обладать слишком большой гибкостью) от функциональности плагинов.

Я обнаружил, что принцип IOC (Inversion of Control) (читайте springframework) хорошо работает для обеспечения гибкой базы, к которой можно добавить специализацию, чтобы упростить разработку плагинов.

• Вы можете сканировать контейнер для механизма "интерфейс как реклама типа плагина".
• Вы можете использовать контейнер для внедрения общих зависимостей, которые могут потребоваться плагинам (например, ResourceLoaderAware или MessageSourceAware).

Я опишу довольно простую технику, которую я использовал в прошлом. Этот подход использует отражение C #, чтобы помочь в процессе загрузки плагина. Этот метод можно изменить так, чтобы он был применим к C ++, но вы теряете удобство использования отражения.

Интерфейс IPlugin используется для идентификации классов, реализующих плагины. В интерфейс добавляются методы, позволяющие приложению взаимодействовать с плагином. Например, метод Init , который приложение будет использовать, чтобы указать подключаемому модулю на инициализацию.

Чтобы найти плагины, приложение сканирует папку плагинов на предмет сборок .Net. Каждая сборка загружена. Отражение используется для сканирования классов, реализующих IPlugin . Создается экземпляр каждого класса плагина.

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

Метод Init вызывается для каждого объекта плагина. Ему передается ссылка на объект, реализующий интерфейс приложения: IApplication (или что-то еще, названное специфическим для вашего приложения, например ITextEditorApplication).

IApplication содержит методы, которые позволяют подключаемому модулю взаимодействовать с приложением. Например, если вы пишете текстовый редактор, этот интерфейс будет иметь свойство OpenDocuments , которое позволяет плагинам перечислять коллекцию открытых в данный момент документов.

Эта система подключаемых модулей может быть расширена до языков сценариев, например Lua, путем создания производного класса подключаемого модуля, например LuaPlugin , который перенаправляет функции IPlugin и интерфейс приложения в сценарий Lua.

Этот метод позволяет вам итеративно реализовать ваш IPlugin , IApplication и другие интерфейсы для конкретных приложений во время разработки. Когда приложение будет завершено и хорошо отрефакторировано, вы можете задокументировать свои открытые интерфейсы, и у вас должна быть хорошая система, для которой пользователи могут писать свои собственные плагины.