Приложение разбитое на dll

[yahont]

Использовать dll библиотеки есть смысл лишь в том случае когда, вы хотите туда вынести ценую часть кода, для коммерческого распространения или в случае если в сложном проекте предусматривается помодульная модернизация приложения БЕЗ перелинковки всего проекта.

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

 

[kapguokog]

Не так давно писал проект на Delphi, выручило использование BPL в качестве плагинов к основной программе. Удобный механизм, прост в освоении.

 

[delphialex]

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

Dll имеет смысл писать, если только планируется их вызов из других языков.
Понятно, что при возможности таких вызовов придется отказаться от
использования специфичных для Delphi типов данных (например, длинных строк).

Если все-таки тянет на эксперименты, то bpl - разумная альтернатива dll в Delphi.

 

[vovag3074]

Например, программа должна работать под разными операционками

 

[FILLrate]

Не понимаю, в чем проблема отладки приложения, разбитого на модули?
У меня таких несколько проектов - никаких проблем. То ж самое с помещением туда графики.


Второй вопрос, почему вместо "родных" bpl надо использовать dll?

Добавлено через 11 минут

Использовать dll библиотеки есть смысл лишь в том случае когда, вы хотите туда вынести ценую часть кода, для коммерческого распространения или в случае если в сложном проекте предусматривается помодульная модернизация приложения БЕЗ перелинковки всего проекта.

Глупости!

dll/bpl нужны для сегментирования проекта, динамической загрузки нужного и выгрузки ненужного кода, упрощения работы над проектом для нескольких человек и т.п.

Я б сказал так, если есть время и возможность, то использовать bpl рекомендуется для любого мало мальски большого проекта (пару десятков форм). Плюс советую освоить механизм визуального форм наследования.

 

[kemash]

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

 

[AlekVolsk]

А меня больше интересует другой вопрос:
В одной dll - модуль данных с доступам к различным БД (одного формата), используемых одновременно. Во всех остальных dll - различные самостоятельные независимые друг от друга модули программы, каждый из которых содержит от 20 до 100 форм (не считая диалогов и прочего функционала, используемого сразу в нескольких модулях, вынесенного в отдельную dll), где имеются только TDataSource, ссылающиеся на TDataSet в dll с модулем данных.
По сути сейчас в каждой dll - свой модуль данных, задача - вывести его в отдельную dll.
Пока даже браться боюсь, хотя мысль мусолю ухе более года, да только не знаю с какой стороны начать. Жажду мыслей.

 

[yahont]

AlekVolsk, Каждая dll, это ведь отдельно взятый проект. Ты хоть представляешь себе, что значит отладить приложение состоящее их 20-100 окон каждое из которых заключено в dll? Да это гарантированный вынос мозга. А как этот подходж усложнит разработку и написание программы в целом? А как искать ошибки... А как быть если проект не документирован, заброшен хотябы на год, а потом его надо подымать и дорабатывать/дополнять/пределывать..

Лучше без нужды не связыватся с dll-ками.
Отладка сложного приложения и без них, иногда проблемная, так что на отладку отельно взятой подсистемы или даже класса, приходится писать маленькую програмку и там отлавливать все детали и перекосы разрабатываемого подобъекта.

 

[wix]

Был такой бесплатный компонент TUilPluging потом его купила TMS и на нем построили свой TMS Pluging. меня с помощью него написано достаточно много приложений. Все прекрасно отлаживается.

 

[svtpro]

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

 

[pppDSV]

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

 

[StrikerLoner]

в Delphi лучше использовать пакеты (BPL) так как это вроде обычная DLL-ка, только её саму можно реализовать как полноценный проект, оттестить нормально а после собрать и поместьть в другой проект

 

[StrikerLoner]

немного поясню свой предидущий пост. Мне необходимо было сделать именно вот такую програму проботающую на плагинах. т.е в Основной программе только управление плагинами а весь функционал собственно в плагинах. Я пробовал делать в DLL-ках - Эт жуткий геморой потому как баги не избежны, а их отлавливание превращается непонятно во что, тогдаа стал копать в сторону пакетов и RTTI, для Delphi 2010 и выше при использовании атрибутов вобще все стало очень простым и не проблематичным, в пакет модно засунуть как сам код так и форму, ресурсы и прочее, прочее, прочее. А отладка соответственно в разы проще, т.к изначально делаем проект под нужный функционал, гоняем его и тестим в результате получаем фактически один класс, вот его то со веми вспомогательными модулями и засовываем в пакет. В дальнейшем данный пакет можно бутет подгрузить и создать нужный объект

 

[white_nigger]

Если пишешь на Delphi - забудь о DLL. Там надо использовать пакеты BPL - это особый вид dll в которые специально заточены для этого. Хорошая статья по системе плагинов есть на блоге Gunsmoker-а