到目前为止,我只发现了这种解决方案的缺点:
我必须将所有公共接口单元放在单独的包中,以便在加载插件时不会出现关于其他包中包含公共单元的错误
如果,假设,一个插件开发人员决定使用一些众所周知的单元(如 synapse),它默认没有运行时包,并且第二个插件开发人员也这样做,则“磕碰”...会在这里崩溃...
提前感谢您的回答
我必须将所有公共接口单元放在单独的包中,以便在加载插件时不会出现关于其他包中包含公共单元的错误
如果,假设,一个插件开发人员决定使用一些众所周知的单元(如 synapse),它默认没有运行时包,并且第二个插件开发人员也这样做,则“磕碰”...会在这里崩溃...
BPL存在另一个缺点。当您切换Delphi版本时,您将不得不重新分发新的插件。在尝试找到完美的插件系统后,我最终选择了COM,并且从未后悔过这个决定。在一款商业应用程序中,其插件需求已超过8年,该应用程序仍在不断发展,但是一些随第一次迭代发布的插件仍以其原始形式存在。
如果您选择此方法,请自己办好事,并从简单的接口开始,然后再添加新接口。您不希望改变您的基本接口,因此保持简单而甜美。
简而言之:如果插件架构是开放的,请将其制作为DLL。否则,人们必须拥有完全相同的Delphi版本才能编写插件。
混合使用也是可能的。您自己和选定的开发人员的功能的更高级别的.BPL接口,以及其他人的底层过程DLL接口。
第三个选择是使用DLL,但指定Sharemem。字符串将起作用,多个Delphi版本将起作用。对象可以工作,但不安全(例如,我猜D2009与早期版本不起作用)。甚至其他语言的用户也可以通过COM进行分配,但并非完全排除非Delphi。
我对JvPluginManager不熟悉,但这取决于您如何使用BPL。
基本上,BPL只是一个普通的DLL,但它的初始化/终止工作从DllMain中剥离出来,分别由“Initialize”和“Finalize”函数执行。
因此,如果您像使用普通DLL一样使用BPL,则我所知道的唯一优点就是没有更多与DllMain相关的问题。那就是全部区别。
但在Delphi中,BPL还提供了一种方便的代码共享方式。这意味着有很多优势(公共内存管理器,无重复代码等等)。因此,通常的BPL做的事情比“只是DLL”多得多。
但这也意味着,现在您的插件系统仅限于Delphi(好吧,也可能是C ++ Builder)。即插件和exe必须在相同的编译器中编译才能平稳运行。
如果这对您可接受(即不使用MS Visual Studio),那么请继续使用BPL的所有功能。
P.S. 但如果您没有仔细设计接口端,升级此类BPL插件也可能成为噩梦。在某些最坏的情况下,您可能需要重新编译所有内容。
P.P.S. 正如我所说的:我不知道它如何应用于JvPluginManager创建的插件。
避免使用bpl方法,因为您将不得不随软件一起发送一个大的bpl包,从而使分发变得笨重。
我们为什么要使用Delphi编译小型独立程序,这些程序可以在任何地方运行而不需要任何运行时依赖关系。使用bpls意味着打败了这个目的。
我不知道您对DLL的熟悉程度如何,但我建议您使用DLL。