在Delphi中，我应该将共享单元添加到我的项目、共享包中，还是两者都不添加？

这个问题类似于，但不是重复的，因为我问的是那个问题中没有讨论的问题

我在Delphi 7中有一个具有以下目录结构的客户机-服务器项目：

\MyApp
  \MyClientApp
  \MyServerApp
  \lib

有两个实际的Delphi项目（.dpr），分别位于MyClientApp和MyServerApp文件夹中

lib文件夹具有.pas单元，这些单元具有客户端和服务器应用程序的通用代码。我想知道的是，我是否应该在客户端和服务器项目中包含这些.pas文件？或者我应该在lib文件夹中创建一个包含这些单元的包？或者我应该将.pas文件放在lib文件夹中，而不将它们添加到任何应用程序/软件包中吗

每种方法的优点/缺点是什么？哪条路是“最好的”？将lib文件夹中的这些单元包含在多个项目中是否有任何问题

现在，lib文件夹中的单位不是任何应用程序/软件包的一部分。这样做的一个缺点是，例如，当我在Delphi中打开客户端应用程序时，我想在项目中的所有文件中搜索某个内容，但它不会在lib文件夹中的单位中搜索。我通过打开这些单元并在所有打开的文件中查找，或者使用grep搜索（但我更喜欢更好的解决方案）来解决这个问题

---

我也非常喜欢这样一种解决方案：当我对lib文件夹中的文件进行更改时，我不必打开一些单独的包并重新编译它（这是我应该使用项目组的地方吗？）。

我通常创建一个包含所有共享单元的包，并且只使用单元。

---

如果您没有明确标记“使用运行时包生成”，包内容（所有使用的dcu）将作为任何其他单元链接到您的项目。

我不喜欢项目共享文件。通常，您会试图编辑其中一个共享文件，您可能会破坏另一个项目中的某些内容，或者您会忘记必须重新生成另一个项目

当共享文件被分离到它们自己的库（包）中时，编辑它们就有了额外的障碍。我认为这是件好事。这将是一个轻松的提示，提示您正在从特定于项目的代码切换到共享代码。可以使用项目组将每个项目集中在一个IDE实例中。在可执行项目之前安排库项目。“buildall”命令将从第一个项目开始按顺序构建所有内容

将DCU文件与PAS文件分开。您可以通过设置“DCU输出目录”项目选项将包的单元发送到其他位置来轻松完成此操作。然后将目标目录放在其他项目的“搜索路径”上。他们会找到DCU，但找不到PAS文件，因此其他项目不会意外地重新编译不是真正成员的单元

---

拥有单独的包也不鼓励使用特定于项目的条件定义。当您在项目之间共享单元时，这些会导致各种各样的麻烦。找到一种方法，将所有特定于项目的选项保留在各自的项目中。共享库不应该需要特定于项目的修改。如果库需要根据使用它的用户的不同而采取不同的操作，则应采用回调函数等技术，库用户可以设置这些回调函数来修改库的行为。

在应用程序之间共享单元总是会带来在一个应用程序中所做的不兼容更改破坏另一个应用程序的风险。另一方面，复制这些单元更糟糕，因此您将它们移动到自己的子目录的方法至少会在不考虑其他程序的情况下改变它们，增加心理障碍

至于将它们添加到项目文件中：我通常将一些我经常从IDE访问（用于扩展或引用）的单元添加到项目中，并将其他单元留给编译器使用搜索路径选择。我是根据每个项目来做的，也就是说，一些单位可能是几个项目的一部分，为什么不呢

如果您真的想创建一个基于包的应用程序，那么将它们放入包中才有意义，否则，为什么还要麻烦呢

---

有关如何组织项目和库的详细信息，请参见

我需要有一个很好的理由向包中添加共享代码。如果您只有几个共享文件，请将它们全部粘贴到名为shared的目录中。这将使文件在项目之间共享变得显而易见

还可以使用一个好的构建工具来进行自动构建，这样，如果您破坏了某些东西，您将很快发现

---

.bpl文件对于组件来说是不错的，但是对于类似这样的事情，它会带来严重的复杂性，除非您有大量的共享文件。

如果您实际上有两个二进制文件，它们应该运行在同一台物理机上，并且共享一些代码，那么我只会使用运行时包。请记住，运行时包主要是一种全有或全无的方法。一旦您决定使用它们，您也将不再能够将RTL和VCL单元直接链接到您的项目中，而必须单独部署它们

然而，当与项目组结合时，包可能仍然是解决问题的好方法，这正是我正在做的。我讨厌在多个项目中包含共享单元。在包中包含共享单元（但不使用运行时包编译实际项目）允许您将该包添加到项目组中，这样您（和IDE！）将始终可以轻松访问这些单元，并且与特定于项目的代码很好地分离。严格地说，您甚至不必编译这些包。他们只能作为项目经理的组织单位

请注意，对于“在文件中查找”，您还可以指定“在项目组中的所有文件中”

包将完全不被链接。它将只链接DCU文件