Система плагинов для приложения Delphi - bpl vs dll?

Еще один недостаток BPL. При переключении версий Delphi вам придется повторно распространять новые плагины. После многих попыток найти идеальную систему плагинов я остановился на COM и ни разу не пожалел об этом решении. В коммерческом приложении, которое требует наличия плагинов более 8 лет, приложение продолжает развиваться, и все же некоторые плагины, выпущенные с первой итерацией, все еще существуют в своей ОРИГИНАЛЬНОЙ форме.

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

Как сказал Александр, BPL - это в основном DLL. Но есть некоторые условия (из не очень краткого резюме, которое я сделал: http://wiki.freepascal.org/packages):

• Юнит может существовать только один раз в BPL's + Exe. Это позволяет избежать дублирования состояния (в два раза больше диспетчера кучи и других глобальных переменных системы и т. Д., Таблиц VMT и т. Д.)
• .BPL могут ИСПОЛЬЗОВАТЬ только другие .BPL.
• Это означает, что динамические типы, такие как ansistring и IS / AS, правильно работают через интерфейсы BPL.
• Инициализация / завершение - это отдельная процедура, и порядок их инициализации строго контролируется. Для статической динамической загрузки это проще, для динамической загрузки (как плагин) проверяются все зависимости от модулей.
• По сути, все представляет собой одну большую программу, а это означает, что BPL должны быть скомпилированы с той же версией компилятора и RTL и зависят от других версий. Может быть сложнее сделать .BPL подключаемыми к существующему EXE, поскольку версия Delphi должна совпадать.
• Это также означает, что вы должны поставить .dcp для (не Delphi) .BPLs, от которых зависит плагин .BPLs

Вкратце: если архитектура плагина открыта, сделайте его DLL. В противном случае люди должны иметь ту же версию Delphi для написания плагинов.

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

Третий вариант - использовать библиотеки DLL, но не использовать Sharemem. Строки будут работать, несколько версий Delphi будут работать. Объекты могут работать, но небезопасны (например, я думаю, например, D2009 с более ранней версией не будет работать). Даже пользователи других языков могут иметь возможность выделять ресурсы через COM, не исключая полностью не Delphi.

Ваш первый минус тоже профи. Если вы реплицируете общий код в каждой DLL, библиотеки становятся все больше и больше. Даже при использовании dll вы можете предотвратить это, переместив общий код в отдельную dll.

Плюсы:

1. Типы общие. Нет TFont - это не проблема TFont
2. Диспетчер памяти общий. Строки и классы можно без проблем использовать в качестве параметров между плагинами.

Минусы:

1. Плагины можно создавать только с использованием Delphi или BCB.
2. Плагины должны использовать ту же версию Delphi или BCB.

Вы рассматривали возможность использования COM? COM позволяет обмениваться типами, строками и классами, а плагины могут быть написаны на многих языках программирования.

Я не знаком с JvPluginManager, но это зависит от того, как вы собираетесь использовать BPL.

По сути, BPL - это просто обычная DLL, но ее инициализация / финализация разделена с DllMain на отдельные функции: 'Initialize' / 'Finalize'.

Итак, если вы собираетесь использовать BPL, как обычную DLL, то я знаю никаких минусов, только плюсы: проблем с DllMain больше не будет. Это все. Единственная разница.

Но BPL в Delphi также предоставляет удобный способ совместного использования кода. Это означает большие преимущества (общий менеджер памяти, отсутствие дублированного кода и т. Д. И т. Д.). Так что обычный BPL делает гораздо больше, чем просто «DLL». Но это также означает, что теперь ваша система плагинов ограничена только Delphi (ну, может быть, и C ++ Builder). Т.е. оба плагина и exe ДОЛЖНЫ быть скомпилированы в одном компиляторе для бесперебойной работы.

Если это приемлемо для вас (т.е. нет MS Visual Studio, нет, сэр, никогда) - тогда вперед, вы можете использовать всю мощь BPL.

P.S. Но обновление таких плагинов BPL также может стать кошмаром, если вы не будете тщательно проектировать интерфейс. В некоторых худших случаях вам может потребоваться перекомпилировать все. P.P.S. Как я уже сказал: я понятия не имею, как это применяется к плагинам, созданным JvPluginManager.

Избегайте подхода blp, так как вам придется отправлять большой пакет bpl с программным обеспечением, и, таким образом, распространение станет громоздким.

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

Я не знаю, насколько вам комфортно работать с библиотеками DLL, но я бы посоветовал вам использовать библиотеки DLL.

• Это даст другим разработчикам (которые могут заинтересоваться вашим программным обеспечением) возможность использовать любой язык разработки (при условии, что этот язык может выдавать dll) для написания своих собственных подключаемых модулей, которые могут быть использованы в разработанном вами программном обеспечении.
• Другое дело, что вы будете избавлены от тирании зависимостей версий vcl в Delphi. Основное слабое место Delphi на сегодняшний день.