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

Я пишу delphi-приложение, которое должно иметь возможность загрузки плагинов. Я использую JvPluginManager как плагин system/manager;) Теперь, в новом мастере плагинов, они говорят, что лучше использовать плагины типа .bpl вместо плагинов .dll... Каковы преимущества этого решения в сравнении с плагинами типа dll? До сих пор я нашел только недостатки этого решения:

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

Итак, каковы на самом деле плюсы использования bpls вместо dll, скомпилированных с пакетами времени выполнения?

Заранее спасибо

Ответ 1

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

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

Ответ 2

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

Единица может существовать только один раз в BPL + Exe. Это позволяет избежать дублирования состояния (дважды heapmanager и другие глобальные vars системы и т.д., Таблицы VMT и т.д.).
.BPL может использовать только другие .BPL.
Это означает, что динамические типы, такие как ansistring и IS/AS, работают над интерфейсами BPL.
Инициализация/финализация - отдельная процедура, и их порядок инициализации строго контролируется. Для статической динамической загрузки это проще, для динамической загрузки (в виде плагина) проверяются все зависимости от единиц.
Все по сути является одной большой программой, что означает, что BPL должен быть скомпилирован с той же версией компилятора и RTL и зависит от версий других зависимостей. Это может быть сложнее сделать .BPL для плагина для существующего EXE, так как версия Delphi должна соответствовать.
Это также означает, что вы должны доставлять .dcp для (не Delphi).BPLs плагины .BPL зависят от

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

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

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

Ответ 3

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

Плюсы:

Типы разделяются. Нет TFont не является проблемой TFont.
Менеджер памяти является общим. Строки и классы могут использоваться как параметр между плагинами без проблем.

Минусы:

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

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

Ответ 4

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

В принципе, BPL - это обычная DLL, но его работа по инициализации/завершению лишается DllMain для разделения функций: "Инициализировать" / "Финализировать".

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

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

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

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

Ответ 5

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

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

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

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