这是我开始here的讨论的延续。我想找到一种模块化Delphi源代码的最佳方法,因为我对此领域没有经验。您的所有建议,我将不胜感激。
让我发布我已经写过的there。
由我工作的公司开发的软件包含100多个模块(其中大多数是类似用于不同设备的驱动程序)。它们中的大多数共享相同的代码-在大多数情况下是类。问题在于,这些类并不总是放在单独的独立PAS单元中。我的意思是,共享代码通常被放入包含特定于模块的代码的单元中。这意味着,当您修复共享类中的错误时,将定义的PAS单元复制到所有软件模块中并重新编译它们是不够的。不幸的是,您必须将固定的代码片段逐一复制并粘贴到每个模块中,并粘贴到适当的单元和类中。这会花费很多时间,这就是我想在不久的将来通过选择正确的方法消除的方法-请帮助我。
我认为使用与EXE一起分发的BPL是一个很好的解决方案,但是它也有一些缺点,如前面的讨论中提到的那样。最严重的问题是,如果每个EXE需要多个BPL,我们的技术支持人员将不得不知道哪个EXE需要哪个BPL,然后为最终用户提供适当的文件。只要我们没有软件更新程序,这对于我们的技术人员和最终用户都是非常重要的。他们一定会迷路和生气的:-/。
还会发生兼容性问题-如果一个BPL被许多EXE共享,则对该BPL的修改可能对一个EXE有利而对其他EXE不利。
那么,我应该怎么做才能在许多项目中更快地修复错误?我想到了以下方法之一。如果您有更好的主意,请告诉我。
就很少修改的代码而言,这种解决方案似乎是可以的。但是我们也有具有常规功能和程序的pas单元,这些单元和功能经常会进行修改。每当有人向该文件添加新功能时,就不可能执行相同的过程(复制和重新编译如此多的项目)。
对我来说,这似乎是最好的解决方案,但是有一些缺点。如果我在BPL中进行错误修复,则每个程序员都必须在其计算机上更新BPL。如果他们忘记了该怎么办?但是,我认为这是一个小问题。如果我们愿意互相告知变更,那么一切都会好起来的。你怎么看?
请帮助我选择一个好的解决方案。我只是不希望公司因为错误的软件开发方法而在错误修正上浪费不必要的时间和金钱。到目前为止,没有人关心它,您可以想象它会导致多少问题。
非常感谢你。
最佳答案
你说:
您不能将BPL链接到可执行文件中。您只需链接同样位于BPL中的单独单元。这样,您实际上根本不需要使用BPL,甚至根本不需要BPL。
BPL旨在用作共享代码,即,您将共享的代码放入一个或几个BPL中,并使用每个.exe,.dll或其他.bpls中的代码。错误修正(如果它们不更改BPL的公共(public)接口(interface))仅需要重新分发该固定BPL。
就像我说的,确定DLL的公共(public)接口(interface),然后不要更改它。您可以添加例程,类型和类,但不应修改任何已在使用的现有类,类型,接口(interface),常量,全局变量等的公共(public)接口(interface)。这样,可以轻松分发BPL的固定版本。
但是请注意,BPL高度依赖于编译器版本。如果使用新版本的编译器,则也必须重新编译BPL。这就是为什么要根据编译器版本给BPL后缀提供100、110等后缀的原因。然后,将指示使用15.0版编译器编译的可执行文件使用带后缀150的BPL,而使用14.0版编译的可执行文件将使用带有后缀140的BPL。这样,不同版本的BPL可以和平共处。可以在项目选项中设置后缀。
您如何管理不同的版本?使用类似于我的ComponentInstaller BPL的目录创建目录(这是您可以在Delphi/C++ Builder/RAD Studio XE IDE的菜单Components-> Install Component下看到的专家):
Projects
ComponentInstaller
Common
D2007
D2009
D2010
DXE
Common目录包含每个版本共享的.pas文件和资源(位图等),每个Dxxxx目录包含该特定版本的BPL的.dpk,.dproj等。每个软件包都使用Common目录中的文件。当然,可以同时为多个BPL完成此操作。
顺便说一句,版本控制系统可能会使这变得容易得多。只要确保为BPL的每个版本都赋予不同的后缀即可。
如果您实际上需要独立的可执行文件,则无需使用BPL,只需在单独的单元中进行链接即可。选项“使用BPL编译”对此进行了控制。
关于delphi - Delphi中最好的模块化编程方法,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/7067338/