Наши преимущества

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

krivetko-man

Турист
Credits
0
У меня есть довольно сложная программа, в которой четко выделяются несколько функциональных блоков. В первый раз в жизни решил разбить программу на библиотеки и заодно улучшить все блоки (переписать заново).

Поделитесь пожалуйста методикой реализации данной идеи!:) какие плюсы и минусы меня жрут? Как обеспечить взаимодействие? Как обеспечить совместимость? Как лучше грузить модули? - статически или динамически?

Спасибо.
 
Если грамотно разделить то минусов наверное не будет.
А если в нескольких dll будет использоваться графический интерфейс делфи то наверное будет минус в том что каждая dll будет содержать в себе библиотеку VCL и соотвественно иметь огромные размеры исполняемых файлов. - Можно их отделить и распространять vcl с прогой.
Если загружать dll статически то тормозить будет при запуске приложения, динамически - будет подтормаживать при первом запуске функции из dll.
 
А если в нескольких dll будет использоваться графический интерфейс делфи то наверное будет минус в том что каждая dll будет содержать в себе библиотеку VCL и соотвественно иметь огромные размеры исполняемых файлов.
VCL работает по тому же принципу, что и dll. Весь код VCL находится в библиотеках, подгружаемых при запуске программы (dll со статикой). Сама прога получается небольшой (ну, конечно от объема выполняемых прогой действий).
 
Я могу загрузить свой проект динамично. статическая нагрузка может вызвать проблемы с памятью.
 
Вообще, для сложных проектов как раз и рекомендуется разбитие на модули...

Получится некое подобие runtime-компонентов, распространяемых с программой. Ничего сложного тут нет, все комплексные юниты записать в dll. В основном приложении осуществлять обработку значений функций. Dll грузить лучше все сразу, чтобы только при первом запуске были тормоза, потом всё будет работать плавно... юзвери ведь не любят, когда при нажатии на кнопку вдруг система залагает (будет грузить dll для обращения к какому-либо куску кода)...

Dll-файлы можно прикрепить к exe-файлу (создать 1 общий файл), с помощью пакера, например, от BoxedApp. Тогда загрузка программы будет происходить немного быстрее, а сами библиотеки можно подгружать по мере надобности, чтобы не есть лишней памяти (их копии уже будут в памяти в виде виртуальных файлов). От этого быстродействие модулей не снизится. Хотя сам пробовал всего лишь с парочкой мелких dll (функции игрового движка), возможно с крупными файлами дела обстоят хуже.
 
Плюсы - модульность приложения делает его структуру яснее и для авторов и для тех, кто будет это приложение поддерживать далее. При внесении изменений в код модуля, как правило не требуется перекомпиляция всего приложения, а только данного модуля.
Минус, а вернее сложность, если в модулях (dll) будет графический интерфейс, особенно, если применяются сложные компоненты (DevExpress и т.п.). Будут ошибки при работе с памятью при запуске и завершении работы приложения. Но это все исправляется, просто нужно будет время.
По поводу размеров dll при использовании vcl - сейчас уже не то время когда были сильные ограничения на объем ОЗУ и жестких дисков. Одним мегабайтом больше или меньше - это не принципиально.
Если функции в dll будут постоянно использоваться во время работы приложения, используйте статическую загрузку, если один/два раза или вообще могут быть не задействованы во время работы - используйте динамическую загрузку.
 
Самое главное о чем стоит помнить при использовании длл - общий memory manager (если передаете данные по указателям на обьекты)
 
ShareMem нужно использовать если будут передаваться длинные строки или объекты их содержащие. Без ShareMem можно обойтись, если передавать строки как PChar.
 
krivetko-man, напишите пожалуйста - удалось ли разделить приложение на DLL?

Я в своё время тоже пытался это сделать, но возникло много проблем. Начиная от хэндлов окон (их надо передавать для MDI приложения) и единого стиля в DevExpress, до логических. Не буду подробно описывать все проблемы, но в итоге все вернул в единое приложение.
ShareMem, кстати, не надо использовать начиная с BDS 2006.
 
ShareMem скорее всего уже подключается автоматически.

Добавлено через 1 минуту
krivetko-man, напишите пожалуйста - удалось ли разделить приложение на DLL?

Я в своё время тоже пытался это сделать, но возникло много проблем. Начиная от хэндлов окон (их надо передавать для MDI приложения) и единого стиля в DevExpress, до логических. Не буду подробно описывать все проблемы, но в итоге все вернул в единое приложение.
ShareMem, кстати, не надо использовать начиная с BDS 2006.

Напиши некоторые проблемы. Попробуем решить. Я с этим много раз сталкивался.
 
Последнее редактирование модератором:
Разделять на кучу dll имеет смысл только при крайней необходимости.
Проблем с памятью не избежать. Отладки будет не меряно... А сколько потом вылезет при эксплуатации - ужас
Лучше потратить время с пользой - просто переписать прогу и не лезть в дебри...
Как уже писали проблем с объемом памяти сейчас нет. Тем более если загружать статически. DLL обычно используют когда работает большая группа разработчиков и детально прописан интерфейс между модулями.
 
Я в свое время когда изучал этот вопрос и был сильно разачарован что в Дельфи нет хорошего способа для разделения программы на модули (типа plugins). А разделение на DLL очень не рекомендую, если вы используете какие-либо библиотеки (графика, формы и т.д.). Будет, например, проблема что TForm <> TForm из DLL. :)
 
есть альтернативы. BPL или скриптовой движок, при этом тексты скриптов можно хранить и в DLL, получится компромисс.
 
В VisualStudio есть поддержка ресурс-DLL, в том числе и ресурсов окон диалога.

В Delphi это тоже возможно, но все кодируется вручную.

Если речь идет о динамической загрузке библиотек, то разбивка исходного кода на модули - задача не столь очевидная. Придется определить, какие именно части кода и ресурсы возможно перенести в Dll, придется реализовать вызовы, загрузку и освобождение памяти. Это приведет к существенному изменению и усложнению логики приложения. Да и уровень программирования в этом случае пониже, широко используется Win API, так что Microsoft SDK Help вам в помощь. : )
 
Последнее редактирование модератором:
Верх