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

Question

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

У меня есть клиент-серверный проект в 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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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