Каковы преимущества и недостатки архитектуры, основанной на подключаемых модулях?

Ответ 1

Преимущества подключаемой системы:

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

Но некоторые из этих сильных сторон также являются слабыми местами:

• расширяемость: поддерживает ли интерфейс плагина способы создания плагинов, чтобы расширить приложение или ограничивает расширение. Разработка расширяемости для удовлетворения всех случаев использования часто требует нескольких итераций или чрезвычайно хорошего анализа требований.
• : поставщик плагинов не только должен удостовериться, что интерфейс плагина удовлетворяет требованиям с отступом, ясен и хорошо документирован, но также и может развиваться. Управление версиями и обратная совместимость с существующими плагинами может быть очень сложным. Достаточно сложно, что многие практические реализации не беспокоят, и нажимать onus на плагинов, чтобы обновлять свои плагины с каждой версией.
• сложность: хотя каждый плагин работает только при тестировании, взаимодействие между плагинами может вызвать новые проблемы, причем ошибки появляются только с некоторыми комбинациями плагинов.
• Тестирование: тестирование плагинов может быть затруднено, если система плагинов не предоставляет некоторую форму макетного плагина для тестирования, что иногда невозможно, а тестирование доступно только при запуске плагина для реального, что замедляет разработку.
• искусственное разделение: плагин, как правило, имеет один фокус, но то, что составляет один фокус, задается провайдером плагинов api. Если писатель-плагин считает, что ему нужен плагин, который может разумно сделать 2 вещи (как определено плагином api) в тесном тандеме, ему может потребоваться реализовать два плагина и найти способы обеспечения связи между ними, которые в настоящее время не предоставляются апи. Затем он должен работать или против рамки плагина.

У разработки хорошей среды плагинов есть те же проблемы, что и проектирование хорошей библиотеки. Если вы сами создаете среду и плагины, то это не так уж плохо, поскольку вы можете обновлять все плагины по мере развития среды, но если плагин api открыт для всех, тогда он требует тщательного планирования и выполнения, чтобы получить дизайн чтобы избежать слишком большого количества перезаписываемых плагинов по мере развития среды.

" синдром второй системы", описанный Фредом Бруксом, утверждает, что вторая разрабатываемая система часто является чрезмерно общей, нацеливаясь на максимальную гибкость, иногда производя "платформа внутри платформы" / " эффект внутренней платформы". Сменный дизайн часто рассматривается как выход, когда требования отсутствуют или не указаны. Чтобы компенсировать это, программное обеспечение сделано максимально гибким, чтобы попытаться справиться с "тем, что приходит".

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

Ответ 2

Преимущества архитектуры подключаемого модуля, очевидно, являются увеличением гибкости. Это позволяет другим разработчикам расширять ваше приложение способами, которые не ожидались в первую очередь. Обратите внимание, что существуют различные плагины, от гибкой до экстремальной гибкости. Самый гибкий метод называется Full Plug-in, который используется в eclipse.

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

Для обсуждения того, как создать архитектуру подключаемого модуля, просмотрите этот вопрос.

Ответ 3

Хотя его нелегко поддерживать плагиновую архитектуру, почему люди так развиваются? Потому что еще лучше, чем другие "фиксированные" подходы. Скажите, если ваши требования меняются один за другим, а дизайн должен быть исправлен, тогда подумайте, что будет делать с другими подходами?

Лучше всего это параллельное развитие. Когда клиент хочет некоторые функции ASAP, разработчики могут работать параллельно и подключать свой код в виде плагинов/компонентов. В принципе архитектура Plug-n-Play обеспечивает гибкость со сложностью, но сложность в первый раз. Как только ваша команда устраивает его, его легко справиться с кодом, ошибками и т.д.

Если вы хотите интегрировать различные сторонние приложения, как вы упомянули, лучше будет разработать его как компонент плагина OR/Service. (Я не хочу вас путать, но SOA может представлять интерес.) Чтобы вы могли включить/отключить сервис/плагин, когда он не нужен. Даже вы можете воспользоваться этим, когда хотите сделать SAAS (программное обеспечение как услугу), где вы получаете доход для каждой отдельной услуги/функции:).

Для справки вы можете проверить следующие рамки JAVA. Существует множество ESB, которые обеспечивают архитектуру plug-n-play на основе компонентов/услуг.

• jBPM (JBOSS Business Process Manager)
• Apache ServiceMix (корпоративная служебная шина)

Надеюсь, это поможет.

спасибо.

Ответ 4

Вы можете найти преимущества и небольшую плагиновую структуру, которую вы можете использовать в текст ссылки