如何将一个程序的各个模块拆分成DLL又能保持逻辑上的可访问性

Question

  我现在负责的程序中由于有很多客户定制性的要求，导致改程序版本很多。代码无法统一。所以我准备把这个程序做成一个EXE+多个DLL的形式，用不同的DLL来实现用户的定制性开发。
但是如果这样做的话。由于之前系统中各个模块之间的联系比较紧密。所以如果拆分成DLL.那么这些DLL无法互相访问。有些全局性的配置信息也无法取得。而且如果独立成DLL.那么这些DLL中都会自带公用函数库。这样一来无法保证这些函数库版本一致。
  请问针对这种情况有没有什么好的解决办法？

Answer 1

定义清晰的接口,保证可访问性,使用ShareMem来达到某些公用数据的相互访问等等.

Answer 2

使用Runtime packagesProject Options->Packages->
√Build with runtime packages
vcl;rtl;这样vcl的对象就能共用、Dll和普通程序就一样写了。自带公用函数库也可以编译成bpl。-------关键的你得分析模块与模块间的调用接口，将独立的功能进行分离和封装。

Answer 3

汗,我还真没有想到过要用BPL,主要是现在基本上都要与C++做的东西打交道.

Answer 4

 楼主的问题是个大话题啊.
根据不同情况,方案很多,关键是否适合你的情况.比如楼上伴水说的BPL型DLL拆分就是其中一种易行的方案，对原有的代码影响最小。楼主觉得呢？

Answer 5

我的博客里有文章，关于dll封装mdi窗体的，不知道对楼主有没有用可访问性的话，我用的是自定义消息和共享内存

Answer 6

印象中bpl使用了别的bpl的东西时，应用程序就需要同时带上多于一个bpl，但是如果使用DLL做成单例模式的话，就没有这个问题。

Answer 7

BPL使用方便原因在于它的设计机制,它通常不是象普通DLL那样导出函数给别人用. 而是在载入的时候,将自己所包含的类,主动在内存中共享的TRegGroups对象中注册。这样，应用程序不需要区分某个类，是静态编译链接进来的，还是通过BPL方式载入进来的。
非常可惜，有得必有失，
1，开发的时候，应用程序最好保证内存中只有一个RegGroups对象。也就意味着，使用的各个BPL，必须依赖同一个BPL，由这一个BPL提供唯一的RegGroups实例访问。 其实这不太算缺点，倒可以算架构设计约定的注意事项。2，BPL机制绕开了DLL导出函数，给多了自由，带来了灵活性，却牺牲了接口约定的约束力度。
这样，当系统面临部分模块多个版本存在时，就是头疼开始的时候。想要更好的解决版本变化影响，有几个关键之处：
A。 对象的创建与释放过程抽象化。
B。 对象的接口清晰化，稳定化，以及版本变化的应对策略。

Answer 8

首先非常感谢ZSWANG，我准备用PACKAGE来实现程序的模块化。另外，to halfdream
我准备把程序中的几个比较大的模块先用BPL来封装，然后对于需要变动的模块实现不通的BPL。这样在发布的时候发布不同的BPL。这样保证程序的主体框架一致。变动只限制在不同的模块中。然后等这中架构稳定了。我再继续逐步细化各个模块，将变动的部门再提取出来。分成更细的BPL来实现。不知道这样的想法可行不

Answer 9

我把我准备使用BPL的方法写出来，大家看看这样做正确不？
假如我模块化后的程序结构为：一个主程序Main.exe 一个模块CHECK.BPL另一个Query.BPL
我在主程序中分别加载CHECK.BPL和Query.BPL而且保证这两个BPL中的主要功能实现类只有一个实例。
然后如果CHECK.BPL这个模块根据用户需求有所变化，我就重新实现一个NewCHECK.BPL。我在发布程序的时候根据用户需要选择发布CHECK.BPL还是NewCHECK.BPL。通过这种方式一方面使得代码模块化减少模块之间的耦合性，另一方面也保证了程序主版本代码的统一。
大家觉得这样的适用方法可行吗？