11

这是我从这里开始的讨论的延续。我想找到模块化 Delphi 源代码的最佳方法，因为我在这个领域没有经验。我将不胜感激您的所有建议。

让我把我已经写在那里的东西贴出来。

我工作的公司开发的软件由 100 多个模块组成（其中大部分是不同设备的驱动程序）。它们中的大多数共享相同的代码 - 在大多数情况下是类。问题是这些类并不总是放在单独的、独立的 PAS 单元中。我的意思是共享代码通常被放入包含特定于模块的代码的单元中。这意味着当您修复共享类中的错误时，仅将其定义的 PAS 单元复制到所有软件模块中并重新编译它们是不够的。不幸的是，您必须将固定的代码片段一个接一个地复制并粘贴到适当的单元和类中。这需要很多时间，这就是我想在不久的将来通过选择正确的方法来消除的问题 - 请帮助我。

我认为使用与 EXE 一起分发的 BPL 将是一个很好的解决方案，但它有一些缺点，正如前面讨论中提到的那样。最糟糕的问题是，如果每个 EXE 需要多个 BPL，我们的技术支持人员必须知道哪个 EXE 需要哪些 BPL，然后为最终用户提供适当的文件。只要我们没有软件更新程序，这对我们的技术人员和最终用户来说都是一笔大买卖。他们肯定会迷路和生气：-/。

还可能出现兼容性问题 - 如果一个 BPL 由多个 EXE 共享，则对该 BPL 的修改可能对一个 EXE 有利而对其他一些 EXE 不利。

那么我应该怎么做才能在这么多项目中更快地修复错误？我想到了以下方法之一。如果您有更好的想法，请告诉我。

  • 将共享代码放入单独和独立的 PAS 单元中，因此当其中一个有错误修复时，将其复制到所有项目（覆盖旧文件）并重新编译所有项目就足够了。这意味着每个单元的复制次数与使用它的项目数量一样多。

就很少修改的代码而言，此解决方案似乎没问题。但我们也有具有通用功能和程序的 PA 单元，这些单元经常进行修改。每次有人向此文件添加新功能时，都无法执行相同的过程（复制和重新编译这么多项目）。

  • 为所有共享代码创建 BPL，但将它们链接到 EXE，以便 EXE 是独立的。

对我来说，这似乎是现在最好的解决方案，但也有一些缺点。如果我在 BPL 中修复错误，每个程序员都必须在他们的计算机上更新 BPL。如果他们忘记这样做怎么办？但是，我认为这是一个小问题。如果我们注意互相通知变化，一切都应该没问题。你怎么看？

  • 最后一个想法，由 CodeInChaos 提出（我不知道我是否理解正确）。在项目之间共享 PAS 文件。这可能意味着我们必须将共享代码存储在一个单独的文件夹中，并让所有项目都在那里搜索该代码，对吧？我猜，每当需要修改项目时，都必须从 SVN 连同共享文件夹一起下载。共享代码中的每次更改都必须导致重新编译使用该代码的每个项目。

请帮我选择一个好的解决方案。我只是不希望公司因为一种愚蠢的软件开发方法而在错误修复上浪费更多的时间和金钱。到目前为止，没有人关心它，您可以想象它会导致多少问题。

非常感谢你。

4

2 回答 2

5

你说：

  • 为所有共享代码创建 BPL，但将它们链接到 EXE，以便 EXE 是独立的。

您不能将 BPL 链接到可执行文件中。您只是在 BPL 中的单独单元中进行链接。这样，您实际上根本不需要甚至根本不需要BPL。

BPL 旨在用作共享代码，即您将共享的代码放入一个或多个 BPL 中，并使用每个 .exe、.dll 或其他 .bpls 中的代码。错误修正（如果它们不更改 BPL 的公共接口）只需要重新分发一个固定的 BPL。

正如我所说，决定 DLL 的公共接口，然后不要更改它。您可以添加例程、类型和类，但不应修改任何已在使用的现有类、类型、接口、常量、全局变量等的公共接口。这样，可以轻松分发固定版本的 BPL。

但请注意，BPL 高度依赖于编译器版本。如果您使用新版本的编译器，您也必须重新编译 BPL。这就是为什么根据编译器版本为 BPL 提供 100、110 等后缀是有意义的。然后，使用编译器版本 15.0 编译的可执行文件将被告知使用后缀为 150 的 BPL，使用版本 14.0 编译的可执行文件将使用后缀为 140 的 BPL。这样，不同版本的 BPL 可以和平共存。后缀可以在项目选项中设置。

你如何管理不同的版本？使用我的ComponentInstaller BPL 的结构创建一个目录（这是您可以在 Delphi/C++Builder/RAD Studio XE IDE 菜单组件 -> 安装组件下看到的专家）：

Projects
  ComponentInstaller
    Common
    D2007
    D2009
    D2010
    DXE

Common 目录包含每个版本共享的 .pas 文件和资源（位图等），每个 Dxxxx 目录都包含该特定 BPL 版本的 .dpk、.dproj 等。每个包都使用 Common 目录中的文件。这当然可以同时为多个 BPL 完成。

顺便说一句，版本控制系统可能会使这更容易。只需确保为 BPL 的每个版本赋予不同的后缀即可。

如果您确实想要独立的可执行文件，则不要使用 BPL，而只需在单独的单元中链接即可。“使用 BPL 编译”选项控制着这一点。

于 2011-08-15T16:29:31.230 回答
3

从我的角度来看，试图管理像 Delphi 单元、库和可执行文件这样的工件，你在错误的地方搜索。我建议你转过头来，根据设计模式实现来重构代码。

例如，所有常用功能都可以放在一个 Singleton类中，常用类的实例可以用Abstract Factory构造，类可以通过接口的原生 Delphi 实现进行交互，而不是直接使用等等。甚至您也可以选择为项目的所有公共部分实施Facade。

当然，具体的模式选择和实现细节取决于项目的具体情况，只有您可以决定适用于您的情况。我想，在以这种方式进行项目之后，您可以找到更自然的代码组织方式和解决问题的方法。

其他一些事情：

  1. 当然，您必须遵循@CodeInChaos 的建议，在所有项目之间共享一份源文件，而不是手动将其复制到每个项目中。如果您采用某种标准来构建环境，这可能会很有用，这对所有开发人员都是强制性的（相同的文件夹结构、库的位置、环境设置）。
  2. 尝试分析构建和部署过程：对我来说，当解决方案不是使用最新版本的代码构建并且在部署之前没有经过测试时，它看起来很不正常。（这是针对您的“如果我在 BPL 中进行错误修复，每个程序员......”短语）。
  3. 带有独立可执行文件的变体看起来更好，因为显着简化了测试环境的组织和项目部署。只需选择适当的版本控制约定。
于 2011-08-15T18:11:08.457 回答