发信人: edison()
整理人: edison(1999-11-24 07:11:35), 站内信件
|
我的天，我们的思路几乎一模一样！太 Cool 了！
我曾说一个 DW 对应一个 Object 。其实我们的意思是一样的，我可
能漏说了。我的 DW 有些是对应一个表、有些是对应多个表。而且我
的 n_om 是继承 DataStore 的。因此，我已将关于各个表之间的完
整性维护问题全部封装到 of_Update、of_Insert、of_Delete 之类
的函数中。但是我多出来一个 n_cst_object 对象用于表示一个一个
的数据实体（通俗一点就是一条记录！）。我这么做首先解决一个问
题，就是参数传递问题（没有你的那种烦恼）。如何解决等我慢慢说
。同样我和你总结的一样，几乎采用两种风格的 DW ，分别是 Grid
与 FreeForm 。每个 Grid 对应一个 FreeForm ！为此我还专门编了
一个 DataWindow Edit Service 。可以很方便的完成数据浏览、编
辑、增删改等操作。只要完成好两个 DW ，再编少许代码，就完成了
Browse 与 Edit 的界面。而且各个功能模块的界面都类似。因此，
感觉非常统一，比较爽！对了，如果 fanpb 老兄对我的 DW Edit
Serviec 感兴趣我可以寄给你（呵呵，献丑了！）。然后回到解决
参数传递问题。通常我们的程序需要将一个实体（一条记录），传到
另一个窗口。供用户编辑，然后传回主窗口。由于我又一个 object
对象。Object 对象里的属性就是记录的各个字段。所以我为 Object
定义一个函数 of_SetObject ( DataWindow adw_obj, Long al_row )
又由于每个实体对应一个 FreeForm 风格的 DW，这样我的各个窗口之
间的参数传递就只一个 n_cst_object 的对象，同时赋值时也很简单，
调用 of_SetObject 即可（我不会在编辑窗口放置 sle_1、cbx_1之类
的控件，我放的是 FreeForm 风格的 DW ）。这样做软件就模块化一些
也形象一点。而且这种 Object 与函数不用自己编码。我们也做了一个
工具专门根据 DW 生成这种 Object ，Object 中的各个属性、方法等
全部由工具完成，所以还是很方便的。就是还没使用 Orca 直接和 PB
合成。下一步就打算将这些工具使用 Orca 直接与 Pb 合成。到时还得
多多向 fanpb 老兄学习！
但是我对 fanpb 老兄最后一个话题有点疑问。自动生成一个功能
继承后的对象。想必这招一定跟 PFC 学的吧？但是 PFC 的 PFE 层对象
可不是简简单单的直接继承 PFC 层对象。它是一个交替继承的关系。
所以你们自己编程做出一个 PFE 层 PBL，难度很大的！不知你们的扩展
层结构是不是和 PFE 类似？我们现在的结构几乎和 PFC 一样，但是 PFE
层的构造则是手工构造的。
【 在 fanpb (笨笨) 的大作中提到: 】
: 的确，在把开发转向oo之初，面临了许多的问题。那时OO只是一句
: 口号。什么是OO，怎样封装，怎样继承，怎样重载只具有例子级的经
: 验。真到实际产品的开发中，还是感到茫然。经过开发多个OO版本的
: 基础类库的摸索，终于找到一条适合本公司产品开发的OO方法。供参考。
: 1、要自顶向下分析数据关系，把数据分解成多个实体。特别强调，
: 一个实体不一定是一个表，而可能是一个表的组合。例如单据，我们
: 的数据库严格遵守二范式，所以肯定是一个总单细目。有的单据的细目
: 还有明细，一个实体由三个联的表组成:
:
: 一个单据实体：
: 总单：日期、客户...
: 细目：商品、数量、单价、库房...
: 明细：货位，状态，数量
:
: 我们设计数据库必须保持数据的完整性、一致性。所有，这三个表
: 必须看成一个实体。在任何一次commit时，必须保证数据完整一致。这样
: 就跟edison的想法略有不同。封装时只能将三个表的逻辑全部封装，而不
: 能分别封装。
:
: 2、大量使用继承。软件几百个功能中，只有两个功能例外（系统管理），
: 其它功能全部使用继承。
: 如何继承，曾使我们走了不少弯路。一段时间，认为OO应结合系统设计，
: 由商业逻辑导出OO设计。例如把OO设计为***流程等，最终找出一条结合OO，
: 从需求分析到系统设计的方法论。但深入下去，因水平太低，根本走不
: 通。不好意思：后来把OO由战略级下调为战术级。就是让OO起提高开发效率、
: 方便维护的纯技术作用。
: 经过分析，我们的软件功能无非这么几种：
: 1）单表编辑。就是一个表格(grid)Datawindow。有时有卡片datawindow(Fr
: eeform)。
: 2)总单细目。两个表格Datawindow，并且要严格维护对应关系。
: 每个Datawindow都可能有一个FreeForm Datawindow编辑。
: 3)总单细目+明细。三个表格Datawindow。
: 每个Datawindow都可能有一个FreeForm Datawindow编辑。
: 4)其它变形，如单表编辑加一个树形控件显示层次结构。
:
: 经过以上分析，发现不管商业逻辑多么复杂，都最终体现在功能上。而功能
:
: 跑不出以上几种形式。于是下大力气，做好这几个功能的基类（都是uo)。每个u
: o
: 内嵌1-n 个Datastore做为数据存取对象。如果需要编辑，打开编辑窗口，让
: datastore和窗口上的datawindow sharedata。
: 最后再辅以PBORCA.dll调用，自动生成一个功能继承后的对象。这样在做好
:
: Datawindow的前提下，只要输入参数，就能完成一个功能最基本的开发。不需要
: 写
: 写一个字节的代码，有些功能确定这样做的。但大多数功能还要重载事件函数，
: 如
: 相互调用等。
:
: 最终的目标是：让开发人员从大量的技术细节中脱离，集中精力于商业逻辑
: 的
: 实现。并且相对容易维护。基类对了大家都对，基类错了大家都错。
:
:
--
谢谢没有在 "将本文章寄一份给原作者" 处打勾, 再次感谢!
※ 来源:．网易 BBS bbs.netease.com．[FROM: bbs.szptt.net.cn]
|
|