Как можно было бы создать сменное программное обеспечение?


20

Если у вас есть какое-то приложение, и вы хотите, чтобы ваши пользователи могли писать плагины для него, как должно быть разработано приложение?

Что вы должны принять во внимание, какие шаблоны дизайна для этого и т. Д.?


Вспоминаются такие шаблоны, как Наблюдатель, Посредник, Командная реклама и Цепочка ответственности
Mchl

3
@Mchl: Пожалуйста, оставьте свой ответ как ответ, а не как комментарий.
С.Лотт

Вы должны взглянуть на Меф и информацию MSDN
Люк Бос

Я чувствую, что это не достаточно подробно для этого
Mchl

@Mchl: "недостаточно подробно"? Тогда зачем вообще комментировать? Это явно ответ. Пожалуйста, оставьте ответы как ответы.
С.Лотт

Ответы:


13

Это зависит от вашей платформы, но следует помнить о некоторых общих вещах.

Создание версий Что произойдет, если вы обновите свое приложение, все ли старые плагины устареют (проблема Firefox)

Изоляция Могут ли плагины делать что хотят? Ты всегда им доверяешь? Или вам нужно запустить их в какой-то песочнице и запросить разрешения.

Обновления Как вы обрабатываете обновления плагинов?

Безопасность Как вы гарантируете автора плагина, предотвратите спуфинг или обман пользователя при установке вредоносного кода. Обычно решается какой-то подписью кода

Сериализация Часто, когда вы используете какую-то изоляцию, вам нужно сериализовать информацию между различными потоками или процессами. Как вы делаете это наиболее эффективно?

Расширяемость Какие аспекты вам нужно расширить? Как вы максимизируете потенциал плагинов без того, чтобы API становился громоздким.

Если вы нацелены на сторонние разработчики для плагинов, я бы сказал, что самое важное (из моего опыта) - видеть API и классы плагинов полностью отличающимися от остальной части приложения, и сделать его максимально простым для разработки. насколько это возможно. Для архитектуры из основного приложения очень просто «перетекать» в плагины, поэтому авторам плагинов приходится узнавать гораздо больше, чем нужно. Облегчите им задачу, подумайте, какой интерфейс и опыт вы хотели бы использовать в качестве автора плагина.

Другое хорошее мышление - не думать, что «плагин будет делать все эти вещи (в коде), а, скорее,« плагин должен предоставлять эту информацию ». Таким образом, приложение может потреблять необходимую информацию и выполнять фактическую обработку, которая упростит плагин.

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


1
+1 Это не дает прямого ответа на вопрос, но это важные вопросы, которые нужно иметь в виду
Адриано Карнейру

Я полагаю, что эти вопросы были рассмотрены до того, как кто-либо начнет разработку реального механизма расширяемости
Гас

9

Я написал эту статью Code Project об использовании MEF для расширяемости в .NET. Это хорошее введение.

Существуют и другие платформы расширения для .NET, такие как Архитектура надстроек SharpDevelop , Mono.Addins и System.AddIn .

Для Java существует архитектура подключаемого модуля Eclipse .

Общая картина такова:

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

На практике это имеет много общего с внедрением зависимости и паттерном стратегии.


+1 MEF и System.AddIn - хорошие вещи для просмотра. Даже если вы не используете их, они оба показывают хорошие концепции.
RationalGeek

@jkohlhepp - я согласен, и я бы также предложил углубиться в архитектуру SharpDevelop, потому что об этом много написано, он с открытым исходным кодом (как и MEF, кстати), и он хорошо спроектирован.
Скотт Уитлок

3

Вам просто нужно предоставить интерфейс для плагинов.

Он должен содержать хотя бы Activate-Methode (точку входа), но вам также понадобятся такие вещи, как Initialize и т. Д.

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

Кроме того, должно быть некоторое доступное хранилище для данных и объектов хост-приложения, чтобы плагины могли вызывать его подпрограммы. Это легко сделать, используя DI-контейнер типа Unity и позволяя подключаемым модулям получать к нему доступ, чтобы они могли разрешать нужные им сервисы.

Event-Aggregator, вероятно, также является хорошей идеей, поэтому плагины могут генерировать события и реагировать на события других плагинов и хост-приложения в отсоединенном виде. Вы определенно хотите один!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.