在 Delphi 中，我应该将共享单元添加到我的项目、共享包中，还是两者都不添加？
这个问题类似于这个，但不是重复的，因为我询问的是该问题中未讨论的问题。
我在 Delphi 7 中有一个客户端-服务器项目，其目录结构如下：
\MyApp
\MyClientApp
\MyServerApp
\lib
有 2 个实际的 Delphi 项目(.dpr)，MyClientApp 和 MyServerApp 文件夹中各一个。
lib 文件夹包含 .pas 单元，这些单元具有客户端和服务器应用程序的通用代码。 我想知道是否应该将这些 .pas 文件包含在客户端和服务器项目中？ 或者我应该在 lib 文件夹中创建一个包含这些单元的包？ 或者我应该将 .pas 文件留在 lib 文件夹中，而不将它们添加到任何应用程序/包中？
每种方法的优点/缺点是什么？ 哪种方式是“最好的”？ 将 lib 文件夹中的这些单元包含在多个项目中是否存在任何问题？
现在 lib 文件夹中的单元不属于任何应用程序/包的一部分。 这样做的一个缺点是，例如，当我在 Delphi 中打开客户端应用程序，并且我想在项目中的所有文件中搜索某些内容时，它不会也在 lib 文件夹中的单元中搜索。 我通过打开这些单元并在所有打开的文件中查找或使用 grep 搜索来解决这个问题（但我更喜欢更好的解决方案）。
我也非常喜欢一个解决方案，当我对 lib 文件夹中的这些文件进行更改时，我不必去打开一些单独的包并重新编译它（这是我应该使用项目组的地方吗？）。
This question is similar to this one, but not a duplicate because I'm asking about issues not discussed in that question.
I have a client-server project in Delphi 7 with the following directory structure:
\MyApp
\MyClientApp
\MyServerApp
\lib
There are 2 actual Delphi projects (.dpr), one each in the MyClientApp and MyServerApp folders.
The lib folder has .pas units that have common code to the client and server apps. What I'm wondering is if I should include those .pas files in the client and server projects? Or should I create a package in the lib folder which includes those units? Or should I just leave the .pas files sitting in the lib folder and not add them to any app/package?
What are the pros/cons of each approach? Which way is "best"? Is there any issue with having those units from the lib folder be included in more than one project?
Right now the units in the lib folder are not a part of any app/package. One disadvantage of this is that when I have my client app open in Delphi, for example, and I want to search in all files in the project for something, it doesn't also search in the units in the lib folder. I get around this by opening those units and doing a find in all open files, or using grep search (but I'd prefer a better solution).
I would also greatly prefer a solution where I will not have to go and open some separate package and recompile it when I make changes to those files in the lib folder (is this where I should use a project group?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
应用程序之间共享单元总是存在在一个应用程序中进行的不兼容更改会破坏另一个应用程序的风险。 另一方面，制作这些单元的副本甚至更糟糕，因此将它们移动到自己的子目录的方法至少会增加在不考虑其他程序的情况下更改它们的心理障碍。
至于将它们添加到项目文件中：我通常将一些我经常从 IDE 访问（用于扩展或参考）的单元添加到项目中，并保留其他单元以供编译器使用搜索路径进行选择。 我在每个项目的基础上这样做，这意味着某些单元可能是多个项目的一部分，为什么不呢？
如果您确实想创建一个基于包的应用程序，那么将它们放入包中才有意义，否则，为什么还要麻烦呢？
有关如何组织项目和库的更多信息，请参阅 http://www.dummzeuch。 de/delphi/subversion/english.html
Sharing units between applications always carries the risk of incompatible changes done in one application that breaks the other. On the other hand, making copies of these units is even worse, so your approcach of moving them to their own subdirectory at least adds a psychological barrier to changing them without considering other programs.
As for adding them to the project files: I usually add some units which I frequently access (either for expanding or for reference) from the IDE to the project, and leave others out for the compiler to pick using the search path. I do that on per project basis, that means, some units may be part of several projects, why not?
Putting them into a package only makes sense, if you actually want to create a package based application, otherwise, why bother?
For more info on how I organize my projects and libraries, see http://www.dummzeuch.de/delphi/subversion/english.html
我不喜欢项目共享文件。 很多时候，您可能会想要编辑一个共享文件，但您要么会破坏另一个项目中的某些内容，要么会忘记必须重建另一个项目。
当共享文件被分成自己的库（包）时，编辑它们就会遇到一些额外的障碍。 我认为这是一件好事。 这将轻轻提醒您正在从项目特定代码切换到共享代码。 您可以使用项目组将所有项目放在一个 IDE 实例中。 将库项目排列在可执行项目之前。 “build all”命令将从第一个项目开始按顺序构建所有内容。
将 DCU 文件与 PAS 文件分开。 您可以通过设置“DCU 输出目录”项目选项将包的单元发送到其他位置来轻松完成此操作。 然后将该目标目录放在其他项目的“搜索路径”上。 他们会找到 DCU，但找不到 PAS 文件，因此其他项目不会意外地重新编译不是真正成员的单元。
拥有单独的包也会阻碍使用特定于项目的条件定义。 当您在项目之间共享单元时，这些会导致各种麻烦。 找到一种方法来将所有特定于项目的选项保留在各自的项目中。 共享库不应需要特定于项目的修改。 如果库需要根据使用它的人采取不同的行为，那么可以采用回调函数等技术，库用户可以设置这些技术来修改库的行为。
I dislike having files shared by projects. All too often, you'll be tempted to edit one of the shared files, and you'll either break something in the other project, or you'll forget that you have to rebuild the other project at all.
When the shared files are instead separated into their own library (package), then there's a little extra barrier to editing them. I consider that a good thing. It will be a light reminder that you're switching from project-specific code to shared code. You can use project groups to let you keep every together in a single IDE instance. arrange the library projects ahead of the executable projects. The "build all" command will build everything in order, starting with the first project.
Keep your DCU files separate from your PAS files. You can do this easily by setting the "DCU output directory" project option to send your package's units to some other location. Then put that destination directory on your other projects' "search path." They'll find the DCU, but they won't find the PAS file, and so no other project will accidentally recompile a unit that isn't really a member.
Having a separate package also discourages use of project-specific conditional defines. Those cause all sorts of trouble when you're sharing units between projects. Find a way to instead keep all project-specific options within the respective projects. A shared library shouldn't require project-specific modifications. If a library needs to act differently based on who's using it, then employ techniques like callback functions that the library user can set to modify the library's behavior.
我需要有一个很好的理由将共享代码添加到包中。 如果您只有几个共享文件，请将它们全部放在名为 Shared 的目录中。 这应该可以明显看出文件在项目之间共享。
还可以使用一个好的构建工具来进行自动化构建，这样如果你破坏了某些东西，你很快就会发现。
.bpl 文件对于组件来说很好，但是会给这样的事情带来严重的复杂性，除非您有大量的共享文件。
I would need to have a very good reason to add shared code to a package. If you just have a few shared files stick them all in a directory called Shared. This should make it obvious the files are shared between projects.
Also use a good build tool to do automated builds so you will find out soon enough if you break something.
.bpl files are fine for components, but bring in serious added complexity for things like this, unless you have a huge amount of shared files.
我通常创建一个包含所有共享单元的包，然后只使用这些单元。
如果您没有明确标记“使用运行时包构建”，则包内容（所有使用的 dcu）将像任何其他单元一样链接到您的项目。
I usually create a package with all shared unit, and just use the units.
If you do not explicitly mark "Build with run time packages" the package content (all used dcu's) will be linked to your project as any other unit.
如果您实际上有两个应该在同一台物理计算机上运行并且共享一些代码的二进制文件，我只会使用运行时包。 请记住，运行时包主要是一种全有或全无的方法。 一旦您决定使用它们，您也将无法再将 RTL 和 VCL 单元直接链接到您的项目中，而必须单独部署它们。
但是，当与项目组结合使用时，包可能仍然是解决您问题的一个很好的解决方案，这正是我正在做的事情。 我讨厌在多个项目中包含共享单元。 将共享单元包含在包中（但不使用运行时包编译实际项目）允许您将该包添加到项目组中，以便您（和 IDE！）始终可以轻松访问它们，但与特定于项目的项目很好地分开代码。 严格来说，您甚至不必编译这些包。 他们只能充当项目经理中的一个组织单位。
请注意，对于“在文件中查找”，您还可以指定“在项目组中的所有文件中”
I would only use runtime packages if you actually had two binaries that were supposed to run on the same physical machine and that shared some code. Keep in mind that runtime packages are mostly an all-or-nothing approach. Once you decide to use them you will also no longer be able to link the RTL and VCL units straight into your projects and will instead have to deploy those separately as well.
However, packages might still be a good solution to your problem when combined with project groups which is exactly what I'm doing. I hate having shared units included in multiple projects. Including the shared units in a package (but not compiling your actual projects with runtime packages) allows you to add that package to your project group so you (and the IDE!) will always have them easily accessible yet nicely separated from the project-specific code. Strictly speaking you don't even ever have to compile those packages. They can merely serve as an organisational unit in the project manager.
Note that for the Find in Files, you can also specify "in all files in project group"