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

Приведу оригинальный пост
авторТак как давно занимаюсь разработкой масштабирумых систем, вопрос по наращиванию и управлению функционалом приложений интересовал и интересует по сей день. В обзорах статей и собственной практике встретил несколько вариантов обеспечения расширяемости/настраивоемости. Исходные данные беру такие - есть некая ИС, в которой должен быть движок, управляющий поведением приложения. Требуется построить систему плагинов таким образом, чтобы функционал можно было расширять средствами самой ИС и(или) с помощью Delphi. Кросплатформенность и многоязыковость в большинстве случаев не нужна, но вот хотелось бы, я думаю меня поймут, чтобы поддерживались различные версии Delphi. Т.е. основное приложение пусть написано на D5, но вот плагины могли бы быть и на D6, D7 и т.д.

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

2) Гибкие настройки программы. Да, да, да! Бывают фанаты именно этого подхода. На каждую операцию и форму может быть созданы десятки и сотни настроек. Плюсы и минусы, думаю, очевидны. Впрочем область применения тоже.

3) DLL - старые добрые библиотеки. Экспортируют набор функций. Подходят в тех случаях когда основное приложение дополняется сторонними функциями. Чаще всего работа на принцепе Вопрос-Ответ. Плюсы: дешево и сердито, все просто и прозрачно. Минусы: работа с объектами основного приложения уже не так тривиальна, а иногда превращается в головную боль.

4) BPL - пакеты. Специфичные библиотеки для Delphi-програм. Работают замечательно, вдобавок можно интегрировать со средой. Плюсы - расширяемы, наращиваемы. Минусы: любые изменения базовых классов и интерфейсов влекут за собой цепочку перекомпиляций зависимых модулей. Во-вторых написанные на одной версии Дельфи пакеты могут и не "поехать" с другой версией. Т.е. если пишем на D5, уж извините, тогда все все делаем на нем.

5) COM - plugins. По типу того как это реализовано в МС Офисе. Плюсы: Наращиваемо, при использовании диспинтерфейсов не возникает проблем со сменой версии интерфейса. Очень легко наладить связь между плагином и движком приложения. Минусы: работа с объектами требует определенных навыков и знаний, тем более, что многие разработчики считают, что в Дельфи не лучшим образом реализована поддержка COM. Второй минус - невозможность поддерживать разные версии библиотек, потому как они "железно" регистрируются в реестре. Еще важным минусом считаю то, как в COM реализована поддержка событий.

6) Интерфейсные BPL, DLL. Некий гибрид COM и DLL. Работа плагинов реализована не на доступе к компонентам, а доступе к объектам через интерфейс. Плюсы: нет привязки к версии Дельфи - плагин может быть скомпилирован на любом Дельфи, расширяемость тоже на высоте. Минусы - по принципу это теже DLL, COM-ограничен использованием регламентированных интерфейсов, про диспинтерфейсы можно забыть.

Хотелось бы услышать, кто какие технологии применяет для своих задач, или может быть их комбинации.
Какие доводы в пользу каждой из технологий можете привести?
Какую считаете более перспективной?
---
aka VIR. No pity. No mercy. No remorse. No Regret

мод Infernal V. Ravenкакие факторы и как они влияют на обеспечения наращиваемости.
Способы наращиваемости в порядке применения:
1. Настройка штатными средствами, разработка отчетов штатными средствами
2. Написание обработчиков на встроенном языке по регламентам системы
3. Написание новых функциональных модулей средствами системы
4. Написание новых модулей сторонними средствами

1) Встроенный генератор отчетов? Тот же Crystal
2) Нужен ли встроенный язык, ведь его разработка весьма затруднена и дорогостоящая по мат. и временным затратам.
3) Это следует из 2)? Если нет то каким образом?
4) Логично

alex108Лично я решил вопрос маштабируемости достаточно станадартно.
Написано приложение, которое общается с сервером в специальном XML-протоколе.
Вся логика на сервере, весь интерфейс генерится на сервере и передается в виде XML клиенту, который его интерпретирует. Новые задачи - без изменения клиента - создаются мгновенно.
Клиент написан на powerbuilder, сервер Oracle.
Что-то типа XAML, XUL...Тут просматриваются сложности с реализацией такого протокола, а во вторых наращиваемости нестандартного функционала. Кстати как дела со скоростью?