【发布时间】：2011-03-09 16:08:25
【问题描述】：
我正在玩弄使用动态加载 BPL 并将对象实例从主应用程序传递到 BPL 中的方法的想法。这在应用程序和 BPL 使用的单元之间造成了问题。
我编写了一个小型原型来执行此操作，并且很好奇 Delphi 如何在内部管理应用程序中定义的类与 BPL 中定义的类之间的差异。
例如，说一个基本的 Widget 类，如：
TmyWidget = class
private
fId:Integer;
fDescription:String;
public
procedure DoSomething1();
end;
现在应用程序和 BPL 是使用包含 TmyWidget 类的单元构建的。后来，TMyWidget 发生了一些变化，应用程序被重建，但 BPL 没有（反之亦然）。我添加了另一个方法 DoSomething2() 并在应用程序中创建了一个 TmyWidget 实例并将其传递给 BPL 进行处理并输入基本的例子，它奏效了。但它显然充满了潜在的问题。
如果另一个动态加载的 BPL 也使用 TmyWidget，那么事情会变得更加有趣。它似乎有效，但绝对感觉不理想。
主要问题是 - 通常如何在主应用程序和 DLL 或 BPL 之间传递对象？我以前从未尝试过，可能是有充分理由的，但我有一个适合这种方法的想法......
我想最好的方法是序列化对象并将这些字节传递过来并在 DLL/BPL 中反序列化它，这个过程要注意主机和动态加载的模块之间的潜在版本差异，但我希望新的 SimpleSharedMem 选项可能会带来这个新功能而无需序列化开销，但它似乎不是很有用，除非您严格保持应用程序和 dll 在任何共享代码更改上重建......但在这个原型中，应用程序将保持相当稳定，动态加载的模块会随着功能添加到 TmyWidget 而频繁更改。 （服务器应用程序充当基于客户端请求构建 TmyWidget 的工厂，应用程序会将实例传递给各个模块进行处理。）
【问题讨论】：
-
当然正确的解决方案是每个单元只有一个实例。为什么你有两次相同的单位？你不能像大自然一样组织代码来避免这种情况吗？
-
是的，它可以（应该）被重新组织——它开始于一个想法，变成了加载 BPL，而这些 BPL 开始是带有一些共享代码的 DLL，没有分段并且出于某种原因，它起作用了，我有点想知道为什么。