Question

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

让我发一下我已写的there。

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

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

也可能出现兼容性问题 - 如果许多EXE共享一个BPL，那么对一个EXE的修改可能对一个EXE有利，对另一个EXE则有害。

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

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

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

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

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

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

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

非常感谢你。

Answer 1

你说：

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

您无法将BPL链接到可执行文件中。您只是链接在BPL中的单独单元中。这样你根本就不会使用甚至需要 BPL。

BPL旨在用作共享代码，即您将共享的代码放入一个或多个BPL中，并使用来自每个.exes，.dlls或其他.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中的菜单组件 - ＆gt;安装组件下看到的专家）：

Projects
  ComponentInstaller
    Common
    D2007
    D2009
    D2010
    DXE

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

版本控制系统可能会让这更容易，BTW。请务必为每个版本的BPL添加不同的后缀。

如果您确实需要独立的可执行文件，则不要使用BPL并只是在单独的单元中链接。 “使用BPL编译”选项可以控制它。

Answer 2

从我的角度来看，尝试管理像Delphi单元，库和可执行文件这样的工件，你会在错误的地方搜索。我建议你转而开始重构代码，基于Design patterns实现。

E.g。所有常用函数都可以放在一个Singleton类中，公共类的实例可以用Abstract Factory构造，类可以通过本地Delphi实现接口而不是直接使用等等。即使您可以选择为项目的所有常见部分实施Facade。

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

其他一些事情：

当然，您必须遵循@CodeInChaos建议并在所有项目之间共享源文件的一个副本，而不是手动将其复制到每个项目。如果您采用一些建筑环境标准可能会很有用，这对所有开发人员都是强制性的（相同的文件夹结构，库的位置，环境设置）。
尝试分析构建和部署过程：对于我来说，当解决方案没有使用最新版本的代码构建并且在部署之前未经过测试时，它看起来很不正常。（这是为了你的“如果我在BPL中修复错误，每个程序员......”这句话）。
使用独立可执行文件的Variant看起来更好，因为它大大简化了测试环境和项目部署的组织。只需为版本控制选择适当的约定。

Delphi中模块化编程的最佳方法

2 个答案: