В Delphi мне следует добавлять общие модули в свои проекты, в общий пакет или ни то, ни другое?

Этот вопрос похож на этот, но не дубликат, потому что я спрашиваю о проблемах, не обсуждаемых в этом вопросе.

У меня есть проект клиент-сервер в Delphi 7 со следующей структурой каталогов:

\MyApp
  \MyClientApp
  \MyServerApp
  \lib

Есть два актуальных проекта Delphi (.dpr), по одному в папках MyClientApp и MyServerApp.

В папке lib есть блоки .pas, которые имеют общий код для клиентских и серверных приложений. Мне интересно, следует ли включать эти файлы .pas в клиентский и серверный проекты? Или мне следует создать пакет в папке lib, который включает эти модули? Или мне просто оставить файлы .pas в папке lib и не добавлять их ни в какое приложение / пакет?

Каковы плюсы / минусы каждого подхода? Какой способ «лучший»? Есть ли проблема с включением этих модулей из папки lib в несколько проектов?

Сейчас модули в папке lib не являются частью какого-либо приложения / пакета. Одним из недостатков этого является то, что, когда мое клиентское приложение открыто, например, в Delphi, и я хочу найти что-то во всех файлах проекта, оно также не выполняет поиск по модулям в папке lib. Я обхожу это, открывая эти модули и выполняя поиск во всех открытых файлах, или используя поиск с помощью grep (но я бы предпочел лучшее решение).

Я также очень предпочел бы решение, в котором мне не нужно было бы открывать какой-то отдельный пакет и перекомпилировать его, когда я вношу изменения в эти файлы в папке lib (где я должен использовать группу проектов?).


person Liron Yahdav    schedule 12.02.2009    source источник


Ответы (5)


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

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

Помещение их в пакет имеет смысл только в том случае, если вы действительно хотите создать приложение на основе пакета, иначе зачем беспокоиться?

Для получения дополнительной информации о том, как я организую свои проекты и библиотеки, см. http://www.dummzeuch.de/delphi/subversion/english.html

person dummzeuch    schedule 13.02.2009

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

Когда общие файлы вместо этого разделены в их собственную библиотеку (пакет), возникает небольшой дополнительный барьер для их редактирования. Я считаю, что это хорошо. Это будет легкое напоминание о том, что вы переключаетесь с кода конкретного проекта на общий код. Вы можете использовать группы проектов, чтобы их можно было объединить в одном экземпляре IDE. расположите проекты библиотеки впереди исполняемых проектов. Команда «построить все» построит все по порядку, начиная с первого проекта.

Храните файлы DCU отдельно от файлов PAS. Вы можете легко сделать это, установив опцию проекта «Выходной каталог DCU» для отправки модулей вашего пакета в какое-то другое место. Затем поместите этот целевой каталог в "путь поиска" других ваших проектов. Они найдут DCU, но не найдут файл PAS, и поэтому никакой другой проект не сможет случайно перекомпилировать модуль, который на самом деле не является его участником.

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

person Rob Kennedy    schedule 13.02.2009

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

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

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

person Toby Allen    schedule 13.02.2009

Обычно я создаю пакет со всеми разделяемыми модулями и просто использую их. Если вы явно не отметите «Сборка с пакетами времени выполнения», содержимое пакета (все используемые dcu) будет связано с вашим проектом, как с любым другим модулем.

person Cesar Romero    schedule 13.02.2009
comment
Пакет package вообще не будет связан. Он просто свяжет файлы DCU, как любая обычная сборка. - person Rob Kennedy; 13.02.2009

Я бы использовал пакеты времени выполнения только в том случае, если у вас действительно было два двоичных файла, которые должны были запускаться на одной физической машине и совместно использовали некоторый код. Имейте в виду, что пакеты времени выполнения - это в основном подход «все или ничего». Как только вы решите использовать их, вы также больше не сможете напрямую связывать модули RTL и VCL в своих проектах, и вместо этого вам придется развертывать их отдельно.

Однако пакеты могут быть хорошим решением вашей проблемы в сочетании с группами проектов, что я и делаю. Я ненавижу включать общие блоки в несколько проектов. Включение общих модулей в пакет (но не компиляция ваших реальных проектов с пакетами времени выполнения) позволяет вам добавить этот пакет в свою группу проектов, чтобы вы (и среда IDE!) Всегда имели к ним легкий доступ, но при этом хорошо отделенные от конкретных проектов. код. Строго говоря, вам даже не нужно компилировать эти пакеты. Они могут просто служить организационной единицей в менеджере проекта.

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

person Oliver Giesen    schedule 13.02.2009