基于TInterfacedClass的Delphi插件框架的内存管理

Question

对于服务器端插件框架，我想实现公开一个返回类引用（TInterfacedClass）的RegisterPlugin方法的DLL。

主机应用程序然后创建此类的实例，并且实例将在主机线程的上下文中运行。 （这与例如Jedi VCL插件框架不同，后者实例化DLL或BPL中的插件并将实例返回给主机。）

第一个测试显示迄今为止没有问题。但是，我应该知道存储管理存在隐藏的问题吗？正如我在此项目中使用Delphi 2009，FastMM4是默认的内存管理器。

此处插件DLL项目的草图：

library ExamplePlugin; 
uses 
    ... 
type 
    TPluginOne = class(TInterfacedObject, ...) 
    ... 
    end; 

function RegisterPlugin: TInterfacedClass; stdcall; 
begin 
    Result := TPluginOne; 
end; 

exports 
    RegisterPlugin; 

{ TPluginOne } 
// ... plugin class implementation 

begin 
end. 

Answer 1

没有问题与内存管理器，因为FastMM作为EXE和DLL之间的共享内存管理器。但我真的不熟悉在DLL和EXE之间传递纯对象或（最差）元类的概念。问题是，来自EXE的TInterfacedObject与DLL中的TInterfacedObject不一样！当然，他们可能看起来完全一样，但他们不是！如果您曾经为EXE或任何DLL升级Delphi的版本，则需要重新构建所有内容（因此失去了从实现插件框架中获得的任何优势）。

一个更便携的解决方案将是返回一个“工厂接口”，沿着线的东西：

IFactoryInterface = interface 
[GUId-goes-here] 
    function MakeWhateverInterfaceYouNeed: IUnknownDerivate 
end; 

然后导出函数与此签名：

function RegisterPlugin: IFactoryInterface; 

Answer 2

你的代码是不完整的，但是从已包含什么有一个明显的缺陷。

您似乎是从DLL中导出类（TInterfacedClass）。当客户端尝试使用不同版本的Delphi来使用您的类时，这会导致问题。更重要的是，如果他们想用不同的语言编写插件，就会让他们感到无助。

就我个人而言，我会选择一个基于COM的界面，这将允许插件作者使用任何语言创建插件。这实际上是COM发明要解决的问题。

如果您很高兴被限制使用相同的编译器插件和宿主应用程序，并且您更愿意向COM接口公开类，那么您需要确保所有的释放都使用相同的内存管理器作为分配的内存。最简单的方法是使用ShareMem，然后你就会安全。

UPDATE

科斯明在评论所指出的跨越模块边界导出类另一个缺陷。这基本上是你不应该做的事情。 COM是为这个目的而设计的，它仍然应该是你的第一选择。德尔福接口这是COM兼容，所以你可以得到二进制的互操作性同样的好处，而无需创建服务器，注册CLSID的等

我觉得你的插件应该是这样的：

library ExamplePlugin; 

type 
    TPluginOne = class(TInterfacedObject, IPlugin) 
    [GUID] 
    public 
    constructor Create(const Host: THostApp); 
    end; 

function RegisterPlugin(const Host: IHostApp): IPlugin; stdcall; 
begin 
    Result := TPluginOne.Create(Host); 
end; 

exports 
    RegisterPlugin; 

begin 
end.