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

Question

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

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

\MyApp 
    \MyClientApp 
    \MyServerApp 
    \lib 

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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