Система плагинов для приложения Delphi - место рождения по сравнению с dll?
Нет никакого "соглашения", которое требует, чтобы имена таблиц были исключительны.
, Например, у нас была таблица под названием "ОТКЛОНЕНИЯ" на дб, используемом процессом оценки, содержа записи, отклоненные от одного выполнения программы, и я не вижу оснований в не использовании множественного числа для той таблицы (называющий его, "ОТКЛОНЕНИЕ" было бы просто забавно, или слишком оптимистично).
О другой проблеме (кавычки) это зависит от диалекта SQL. Oracle не требует кавычек вокруг имен таблиц.
5 ответов
Еще один недостаток BPL. При переключении версий Delphi вам придется повторно распространять новые плагины. После многих попыток найти идеальную систему плагинов я остановился на COM и ни разу не пожалел об этом решении. В коммерческом приложении, которое требует наличия плагинов более 8 лет, приложение продолжает развиваться, и все же некоторые плагины, выпущенные с первой итерацией, все еще существуют в своей ОРИГИНАЛЬНОЙ форме.
Если вы выберете этот метод, сделайте себе одолжение и начните с простого интерфейса, а затем добавьте к нему новые интерфейсы. Вы не хотите когда-либо менять базовый интерфейс, так что пусть он будет простым и понятным.
Как сказал Александр, BPL - это в основном DLL. Но есть некоторые условия (из не очень краткого резюме, которое я сделал: http://wiki.freepascal.org/packages ):
- Модуль может существовать только один раз в BPL + Exe. Это позволяет избежать дублирования состояний (в два раза больше, чем диспетчер кучи и другие глобальные переменные системы и т. Д., Таблицы VMT и т. Д.)
- .BPL могут ИСПОЛЬЗОВАТЬ только другие .BPL.
- Это означает, что динамические типы, такие как ansistring и IS / AS, работают правильно над Интерфейсы BPL.
- Инициализация / завершение - это отдельная процедура, и порядок их инициализации строго контролируется. Для статической динамической загрузки это проще, для динамической загрузки (как плагин) проверяются все зависимости от модулей.
- По сути, все представляет собой одну большую программу, что означает, что BPL ' s должен быть скомпилирован с той же версией компилятора и RTL и зависит от других версий. Может быть сложнее сделать .BPL подключаемым модулем к существующему EXE, поскольку версия Delphi должна соответствовать.
- Это также означает, что вы должны доставлять .dcp для (не Delphi) .BPLs, от которых зависит подключаемый модуль .BPLs зависят от
Вкратце: если архитектура плагина открыта, сделайте его DLL. В противном случае люди должны иметь ту же самую версию Delphi для написания плагинов.
Гибрид также возможен. Интерфейс более высокого уровня .BPL для функциональности, которую вы сами учитываете в .BPL и выбранных разработках, а также интерфейс DLL процедур нижнего уровня для всего остального.
Третий вариант - использование DLL, но обычный Sharemem. Строки будут работать, несколько версий Delphi будут работать. Объекты могут работать, но они небезопасны (например, я думаю, например, D2009 с более ранней версией не работает) т работать). Даже пользователи других языков могут иметь возможность выделять память через COM, не исключая полностью не Delphi.
Ваш первый мошенник тоже профи. Если вы реплицируете общий код в каждой DLL, библиотеки становятся все больше и больше. Даже при использовании dll вы можете предотвратить это, переместив общий код в отдельную dll.
Плюсы:
- Типы являются общими. Нет TFont не является проблемой TFont
- Диспетчер памяти используется совместно. Строки и классы могут использоваться в качестве параметров между плагинами без проблем.
Минусы:
- Плагины могут быть созданы с использованием только Delphi или BCB.
- Плагины должны использовать ту же версию 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.
PS Но обновление таких плагинов BPL также может быть кошмаром, если вы не будете тщательно проектировать интерфейс. В некоторых худших случаях может потребоваться перекомпилировать все. PPS Как я уже сказал: я понятия не имею, как это применяется к плагинам, созданным JvPluginManager.
Избегайте подхода blp, так как вам придется отправить большой пакет bpl с программным обеспечением, и, таким образом, распространение станет громоздким.
почему мы используем Delphi для компиляции небольших автономных программ, которые просто ЗАПУСТИТЕ где угодно без какой-либо зависимости от времени выполнения. Использование bpls означает поражение именно этой цели.
Я не знаю, насколько вам комфортно работать с DLL, но я бы посоветовал вам использовать библиотеки DLL.
- Это даст другим разработчикам (которые может заинтересоваться вашим ПО) возможность использовать любую разработку язык (если этот язык может dll выплюнуть) написать свои плагины, которые можно использовать в вашем разработанное программное обеспечение.
- Другое дело, что вы будете сохранено из версии Delphi vcl зависимость тирании. Главный слабый точка Delphi до настоящего времени.