我正在编写应该具有加载插件功能的delphi应用程序。我正在使用JvPluginManager作为插件系统/管理器;）现在，在新的插件向导中，他们说最好使用.bpl类型的插件而不是.dll插件...这个解决方案与dll类型插件有什么优点？ 到目前为止，我发现只有这个解决方案的缺点：
我必须将所有通用接口单元放在单独的包中，以便在加载插件时不会抛出包含公共单元的其他包的任何错误
如果，让我们说，其中一个插件开发人员决定使用一些众所周知的单元（如synapse），默认情况下没有运行时包，第二个插件开发人员也会使用碰撞 ......它在这里崩溃......
那么，使用bpls而不是使用运行时包编译的dll实际上是什么呢？
提前致谢
答案 0 :(得分：17)
BPL的另一个缺点。当您切换Delphi版本时，您将不得不重新分发新插件。在尝试寻找完美插件系统的许多尝试之后，我最终得到了COM，我从未后悔过这个决定。在已经有超过8年的插件要求的商业应用程序中，应用程序继续向前发展，但是在第一次迭代中发布的一些插件仍然以其原始形式存在。
如果您选择此方法，请帮自己一个忙，然后从一个简单的界面开始，然后在其上添加新的界面。您不希望更改基本界面，因此请保持简单和甜蜜。
答案 1 :(得分：8)
正如亚历山大所说，BPL基本上是一个DLL。但是有一些条件（从我做的一个不那么简短的总结：http://wiki.freepascal.org/packages）：
简而言之：如果插件架构已打开，请将其设为DLL。否则，人们必须拥有完全相同的Delphi版本来编写插件。
混合动力也是可能的。一个更高级别的.BPL接口，用于功能，你可以将自己和选定的级别分解为.BPL，以及其余部分的底层程序DLL接口。
第三个选项是使用DLL，但是命名为Sharemem。字符串将工作，多个Delphi版本将工作。对象可以工作但不安全（例如，我想例如D2009与早期版本不起作用）。甚至其他语言用户也许可以通过COM进行分配，而不是完全排除非Delphi。
答案 2 :(得分：4)
你的第一个骗局也是职业选手。如果你在每个dll中复制共享代码，dll会变得越来越大。即使使用dll，您也可以通过在单独的dll中移动共享代码来防止这种情况。
优点：
缺点：
您是否考虑使用COM？ COM可以共享类型，字符串和类，插件可以用许多编程语言编写。
答案 3 :(得分：3)
我不熟悉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创建的插件。
答案 4 :(得分：1)
避免使用blp方法，因为你必须随身携带一大包bpl，因此分发会变得笨重。
为什么我们使用Delphi来编译只在任何地方运行而没有任何运行时依赖性的小型独立程序。使用bpls意味着打败这个目的。
我不知道你对DLL有多舒服，但我建议你使用DLL。