不知道能不能算是一个框架，但是请大家近来讨论一下。

[rzg]

（Delphi6）我想把ERP中所有的功能分解成不能再分一个个子功能点。然后每个功能点分别以OCX，DLL来实现。将实现的每个功能点相应文件均放到程序的系统注册表中（非操作系统本身的注册表）然后根据“系统注册表”自动生成相应功能界面。至于实现细节则需要好好讨论。这样做的好处是：再ERP各个子功能点的互相之间只有一般数据耦合，很少的控制耦合，尤其是各个单据之间。这样当增加新的的需求的时候，只需要根据需求类别添加新的OCX or DLL文件，然后在“系统注册表”中注册该子功能项，那么在用户界面中就可以使用该功能了。我想采用OCX 或者DLL的方式，不知道有没其他有好的方式。这么做不足之处是：每个子功能项都得新建工程，每个子功能项的版本一致问题等等，还是希望大家讨论一下。

[dq]

类似的做法我们以前用过，不过废掉了，原因很简单：太庞杂了。
而且事后反思一下才发现这种做法只不过是一种形式，没有实质性的贡献。试问你如何划分这些子功能？怎么把它们统一在一个界面之下？或者说各模块之间的复杂交互怎么实现？另一方面，如果你能把上面的问题规划好了，那么把这些模块当成函数调用又有何不可呢？反正就算是做成DLL之类的东东还是免不了要改动的，并且这种方式实在是弊大于利的。

[rzg]

如果有好的想法可以电子邮件联系[e-mail]

[diruser]

落后的相法，用OOP分析一下

[xxabcun]

我以前公司就是这种思路，效果很差。

[w_rose]

等于没说

所谓的技术化，但是不知道技术要干什么用，等于白痴

[阿博]

一个个子功能点，这些点是以什么为对象的？
从技术架构上看，可以有这么一层。也许还得有更高的一层近（例如：综合控制层），更低的一层（业务操作原子层）。
这样才更灵活与更有扩展性。

我还没有看明白你的意思，不能乱说。。

[arfayr]

太细了，应该再粗一点，比如工序任务管理可以作为一个Ocx MRP运算可以作为DLL，这样好一些。

[_i_]

我也有相同想法，不过我是把它放在数据库里面

[leeyihan]

可以用Package的方式解决，首先定义好框架程序与Package之间的接口函数，每个子功能编译成一个Package，由框架去动态调用。delphi本身提供了这种方法，实现和维护起来比ocx或者dll的方法还要简单。我们正在开发的系统已经有了100-150个左右的子功能，用这种方法可以比较容易地达到协同开发的目的，程序的功能更新也非常方便。多试试。