Mar*_*mke 11 delphi bpl modularization
这是我在这里开始的讨论的延续.我想找到模块化Delphi源代码的最佳方法,因为我在这个领域没有经验.我将感激你的所有建议.
让我发布我在那里写的内容.
我工作的公司开发的软件包含100多个模块(大多数模块类似于不同设备的驱动程序).他们中的大多数共享相同的代码 - 在大多数情况下是类.问题是这些类并不总是放在单独的独立PAS单元中.我的意思是共享代码通常放在包含特定于模块的代码的单元中.这意味着当您修复共享类中的错误时,将其定义的PAS单元复制到所有软件模块并重新编译它们是不够的.不幸的是,您必须将固定的代码片段逐个复制并粘贴到每个模块中,并将其粘贴到适当的单元和类中.这需要花费很多时间,这是我希望通过选择正确的方法在最近的将来消除 - 请帮助我.
我认为使用与EXE一起分发的BPL将是一个很好的解决方案,但它有一些缺点,正如前面讨论中提到的那些.最糟糕的问题是,如果每个EXE需要几个BPL,我们的技术支持人员将不得不知道哪个EXE需要哪个BPL,然后为最终用户提供适当的文件.只要我们没有软件更新程序,这对我们的技术人员和最终用户来说都是一个很大的优势.他们肯定会迷茫和愤怒: - /.
此外,还可能出现兼容性问题 - 如果许多EXE共享一个BPL,则对该BPL的修改可能对一个EXE有利,对另一个EXE则有害.
那么我应该怎么做才能在这么多项目中更快地修复错误？我想到了以下方法之一.如果您有更好的想法,请告诉我.
就很少修改的代码而言,这个解决方案似乎没问题.但我们也有具有一般使用功能和程序的通行单元,这些功能和程序经常进行修改.每次有人向此文件添加新功能时,都不可能执行相同的程序(复制和重新编译这么多项目).
对我来说,这似乎是现在最好的解决方案,但有一些缺点.如果我在BPL中修复错误,每个程序员都必须在他们的计算机上更新BPL.如果他们忘记那样做怎么办？但是,我认为这是一个小问题.如果我们负责通知对方有关变化,一切都应该没问题.你怎么看？
请帮我选择一个好的解决方案.我只是因为一种愚蠢的软件开发方法,我不希望公司在错误修正方面损失比必要的更多的时间和金钱.到目前为止,没有人关心它,你可以想象它会导致多少问题.
非常感谢你.
你说:
- 为所有共享代码创建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中的菜单组件 - >安装组件下看到的专家):
Projects
ComponentInstaller
Common
D2007
D2009
D2010
DXE
Common目录包含每个版本共享的.pas文件和资源(位图等),每个Dxxxx目录包含该特定版本BPL的.dpk,.dproj等.每个包都使用Common目录中的文件.当然,这可以同时针对几个BPL进行.
版本控制系统可能会让这更容易,BTW.请务必为BPL的每个版本添加不同的后缀.
如果您确实需要独立的可执行文件,则不要使用BPL并只是在单独的单元中链接."使用BPL编译"选项控制着这一点.
| 归档时间： |
|
| 查看次数： |
2312 次 |
| 最近记录： |