M
mycpp
Unregistered / Unconfirmed
GUEST, unregistred user!
（以下是我在2001年提出的设计，于去年完全用Midas＋dcom＋OOP实现了一个大型
数据库的开发和实施，总结了一些经验教训，想和正在使用midas的朋友交流，欢迎交
流并回答朋友们关于midas方面的问题。
体会最深的是在一个在大型系统中，技术只占30%，实施占30%，而管理占了40%。
其次是像Delphi、VB、Vfp这种开发工具提供的RAD快速开发手段是让程序员很快上手，
但如果没有很好的OOP分层设计的思想，就只能作一些小的项目。真正的大型应用是
业务是非常复杂的，一定要回到C++那种设计思想时代，抽象出最原始、最小粒度的
TObject，形成一种内核技术，像现代工业化生产的一样，把百万计的晶体管封装成
小小的芯片，所有与业务层的沟通都通过类的方法、事件等完成，才能真正实现软件产
业的工业化。另外，由于采用了这种技术，EXE文件也作的非常小，加上bpl包文件才3M，
但软件的功能已覆盖了大中型企业的主要业务范围，而市面上的这些软件一般都很大。）
三层框架软件生产线
孙辉
gz_sky@163.com
一、目标
生产线内部由框架数据库、框架中间层、函数库、框架表单、控件、MYDBVCL等组成，并有抽象性、层次性、框架性等特点。
外部通过接口，以参数化、元素化等简明的形式提供给其他人员使用。同时，本生产线具有高内聚、松耦合的特点：本身就是一个可
自运行的系统，应用人员对界面的修改不对生产线产生影响。
可见，本生产线使应用人员避免了对软件技术的依赖性，不需要开发经验的积累，而是直接面向业务层，把主要工作放在业务规
则的框架式填写上。
本生产线提交给应用人员的是一批编译文件及DELPHI表单文件，并由应用人员根据不同的行业完成业务规则的填写及操作界面的
修正，最终编译为可执行的三层架构的数据库软件系统。
生产线对数据库没有特别的要求，但数据库的表要从本系统的框架数据库中引用，主要是生产线定义了一些抽象的数据结构，而这
些数据结构是生产线的核心部件，所以数据库的物理表一定要根据本系统的数据结构定义。
二、现有的资源及技术
自1997年以来，我们应用了一些比较初级的基类、框架等技术以加快开发速度，其后几年间不断完善、补充，中间经历了四个版本，
并以数个软件产品验证了软件生产线的可行性和强大性，积累了大量经典应得到应用的Delphi框架代码，最终以三层架构实现了整个体
系。基本上，现在的生产线由以下资源组成：
1.框架数据库
这是系统的核心。生产线之所以能快速加工、生产出不同应用的软件产品，是因为我们设计出了一套抽象数据结构，它基本上可用
于所有行业的数据库。这样，技术就从业务中分离出来：生产线解决的只是我们事先定义好的抽象数据之间的操作，尽管这种操作是非常
复杂，但由于它是脱离了具体业务的，内部就会非常稳定。当然这种抽象也包含通用性，否则它就不能成为生产不同产品的生产线了。
2.框架中间层（商务层）
如上所述，框架数据库解决的只是一种抽象数据，如何加工成不同应用的产品呢？框架中间层提供了两种服务：一是控制数据结构，
二是解释业务规则。不同的业务规则产生了不同的数据控制，也就产生了不同的应用产品。
3.函数库
积累并提供了多年来编写并完善的上万行函数，解决了数据库系统方方面面的技术问题。
4.框架表单
相当于产品的外观设计，应用人员可根据不同行业设计、修改，形成不同的产品风格。它的改变不会对生产线内部产生影响。
框架表单是MDI形式的，同时也是分层结构，极大简化了开发工作的复杂性。
5.控件
主要由我们自己编写的一些控件组成。
6.MYDBVCL
由自已编写的大量底层DBVCL组成，是VCL的三层架构及数据操作的封装，完成了许多VCL不能实现的数据操作功能。
7.其他
主要是一些通用报表、查询等。
8.生产线应用
生产线作为一个独立的开发类产品，在应用采用的是元素赋值及参数重定义的非常简单的代码组装作业方式，以下是一个采购
单的应用，
两段代码就可实现物料采购的基本功能：
procedure TfrmPOrder.FormCreate(Sender: TObject);// 元素赋值，定义是采购单
begin
secondFocus:=dbPickDate;
AppName:='采购合同';
listname:='porder';
detailsName:='Porderd';
tableName:='Porder';
vtable:='porder';
ftypeid:='POrder';
inherited;
end;
procedure TfrmPOrder.SetNextWorkValue;// 参数重定义，指示采购工作流程。
begin
inherited;
with dsListdo
begin
FNextTable:=tableName;//'inventoryIND';//fToDoTable
fNextvtable:=vtable;
FNextBillType:='PlanPurchBill';
FNextAppName:='应处理：订单应交料单';
end;
// with
end;
三、设计要点
1.框架数据库与框架程序的溶合
2.面向对象的设计思想。
系统把现实中的各种事物对应到一个个的对象，并且对象间有各自的继承关系，如采购单是一个TinventoryObj，
它是从TBillObj继承来的。在TbillObj中实现对通用单据的操作，如新增、删除、存盘、放弃修改等。而在TinventoryInObj
中则处理采购单不同于通用单据的操作，这属于业务层。而采购单的窗体TfrmInventoryIn，则是从TfrmBill继承而来，当然，
它们本身也是对象。
系统用很多对象封装了大量的功能，程序员可通过设置一些属性实现对这些对象的控制，并控制整个应用程序。
3. 界面与单元的分离
本系统采用界面与单元分离的设计方案。如上面所说的TbillObj，TiventoryInObj都和界面无关。而在界面方面，系统也是以
面向对象的设计方法，提供一些基类窗体，这些基类窗体（如TFrmBill）与各种数据单元（如TBillObj）配合，完成大量的通用操作，
使程序员在实现具体业务时不必考虑这些繁琐的事情。而在窗体中，各功能都是用TActionList与可视控件连接，使得更改界面与程
序的功能无关。
4.中间层或商务层的灵活运用：
1).前台的功能的工作列表发给业务层时只用一个参数的形式。
2).数据访问层是独立的，它主要的作用是解释SQL语句。
系统把不同的功能放在不同的层次中，有绝对通用的，有在一定的业务范围内通用的，有在每个应用中都会有很大差异的业务层。
3).业务规则建成一个独立的层。
业务规则肯定是要建成一个独立的层，这样在开发下一个项目时，只要修改业务层的单元就可以。这个框架的一个作用就是所有的公
用单元在每个项目里都不需要变动。
5.数据字典建建成一个独立的表。
数据字典是系统中一个独立的可重用的对象，它至少会包含以下表：
数据表表：每条记录对应一个物理上数据表
字段表：为上述表中的字段，包括各字段的字段名、中文标题、显示格式、与其它表的关联方式等。 它主要是反映系统中的数据结构，
在通用查询中，如要筛选InventoryIn表，其中有字段fCustId，但客户不可能用fCustId来指定关于某单位的筛选条件，但借助数据字典，
系统可以查到fCustId是引用Cust表中的fId字段，而Cust表是一个基本资料表，它里面对用户而言可见的字段是编码、名称、类别、电话
号码等。这样的话，系统就可以在查询InventoryIn表时提供适当的界面，让用户可以输入单位编码或是单位名称来提供查询条件。而不
是把设定查询条件局限于InventoryIn表中直接可操作的对象，如日期、单号。
四、 近两年来，我们采软件生产线作业方式组装了几个有一定规模的产品：
如企业质检与物流管理、制造业综合管理系统等等。证明生产线可为软件公
司实现工业化低成本开发的组装作业方式。
数据库的开发和实施，总结了一些经验教训，想和正在使用midas的朋友交流，欢迎交
流并回答朋友们关于midas方面的问题。
体会最深的是在一个在大型系统中，技术只占30%，实施占30%，而管理占了40%。
其次是像Delphi、VB、Vfp这种开发工具提供的RAD快速开发手段是让程序员很快上手，
但如果没有很好的OOP分层设计的思想，就只能作一些小的项目。真正的大型应用是
业务是非常复杂的，一定要回到C++那种设计思想时代，抽象出最原始、最小粒度的
TObject，形成一种内核技术，像现代工业化生产的一样，把百万计的晶体管封装成
小小的芯片，所有与业务层的沟通都通过类的方法、事件等完成，才能真正实现软件产
业的工业化。另外，由于采用了这种技术，EXE文件也作的非常小，加上bpl包文件才3M，
但软件的功能已覆盖了大中型企业的主要业务范围，而市面上的这些软件一般都很大。）
三层框架软件生产线
孙辉
gz_sky@163.com
一、目标
生产线内部由框架数据库、框架中间层、函数库、框架表单、控件、MYDBVCL等组成，并有抽象性、层次性、框架性等特点。
外部通过接口，以参数化、元素化等简明的形式提供给其他人员使用。同时，本生产线具有高内聚、松耦合的特点：本身就是一个可
自运行的系统，应用人员对界面的修改不对生产线产生影响。
可见，本生产线使应用人员避免了对软件技术的依赖性，不需要开发经验的积累，而是直接面向业务层，把主要工作放在业务规
则的框架式填写上。
本生产线提交给应用人员的是一批编译文件及DELPHI表单文件，并由应用人员根据不同的行业完成业务规则的填写及操作界面的
修正，最终编译为可执行的三层架构的数据库软件系统。
生产线对数据库没有特别的要求，但数据库的表要从本系统的框架数据库中引用，主要是生产线定义了一些抽象的数据结构，而这
些数据结构是生产线的核心部件，所以数据库的物理表一定要根据本系统的数据结构定义。
二、现有的资源及技术
自1997年以来，我们应用了一些比较初级的基类、框架等技术以加快开发速度，其后几年间不断完善、补充，中间经历了四个版本，
并以数个软件产品验证了软件生产线的可行性和强大性，积累了大量经典应得到应用的Delphi框架代码，最终以三层架构实现了整个体
系。基本上，现在的生产线由以下资源组成：
1.框架数据库
这是系统的核心。生产线之所以能快速加工、生产出不同应用的软件产品，是因为我们设计出了一套抽象数据结构，它基本上可用
于所有行业的数据库。这样，技术就从业务中分离出来：生产线解决的只是我们事先定义好的抽象数据之间的操作，尽管这种操作是非常
复杂，但由于它是脱离了具体业务的，内部就会非常稳定。当然这种抽象也包含通用性，否则它就不能成为生产不同产品的生产线了。
2.框架中间层（商务层）
如上所述，框架数据库解决的只是一种抽象数据，如何加工成不同应用的产品呢？框架中间层提供了两种服务：一是控制数据结构，
二是解释业务规则。不同的业务规则产生了不同的数据控制，也就产生了不同的应用产品。
3.函数库
积累并提供了多年来编写并完善的上万行函数，解决了数据库系统方方面面的技术问题。
4.框架表单
相当于产品的外观设计，应用人员可根据不同行业设计、修改，形成不同的产品风格。它的改变不会对生产线内部产生影响。
框架表单是MDI形式的，同时也是分层结构，极大简化了开发工作的复杂性。
5.控件
主要由我们自己编写的一些控件组成。
6.MYDBVCL
由自已编写的大量底层DBVCL组成，是VCL的三层架构及数据操作的封装，完成了许多VCL不能实现的数据操作功能。
7.其他
主要是一些通用报表、查询等。
8.生产线应用
生产线作为一个独立的开发类产品，在应用采用的是元素赋值及参数重定义的非常简单的代码组装作业方式，以下是一个采购
单的应用，
两段代码就可实现物料采购的基本功能：
procedure TfrmPOrder.FormCreate(Sender: TObject);// 元素赋值，定义是采购单
begin
secondFocus:=dbPickDate;
AppName:='采购合同';
listname:='porder';
detailsName:='Porderd';
tableName:='Porder';
vtable:='porder';
ftypeid:='POrder';
inherited;
end;
procedure TfrmPOrder.SetNextWorkValue;// 参数重定义，指示采购工作流程。
begin
inherited;
with dsListdo
begin
FNextTable:=tableName;//'inventoryIND';//fToDoTable
fNextvtable:=vtable;
FNextBillType:='PlanPurchBill';
FNextAppName:='应处理：订单应交料单';
end;
// with
end;
三、设计要点
1.框架数据库与框架程序的溶合
2.面向对象的设计思想。
系统把现实中的各种事物对应到一个个的对象，并且对象间有各自的继承关系，如采购单是一个TinventoryObj，
它是从TBillObj继承来的。在TbillObj中实现对通用单据的操作，如新增、删除、存盘、放弃修改等。而在TinventoryInObj
中则处理采购单不同于通用单据的操作，这属于业务层。而采购单的窗体TfrmInventoryIn，则是从TfrmBill继承而来，当然，
它们本身也是对象。
系统用很多对象封装了大量的功能，程序员可通过设置一些属性实现对这些对象的控制，并控制整个应用程序。
3. 界面与单元的分离
本系统采用界面与单元分离的设计方案。如上面所说的TbillObj，TiventoryInObj都和界面无关。而在界面方面，系统也是以
面向对象的设计方法，提供一些基类窗体，这些基类窗体（如TFrmBill）与各种数据单元（如TBillObj）配合，完成大量的通用操作，
使程序员在实现具体业务时不必考虑这些繁琐的事情。而在窗体中，各功能都是用TActionList与可视控件连接，使得更改界面与程
序的功能无关。
4.中间层或商务层的灵活运用：
1).前台的功能的工作列表发给业务层时只用一个参数的形式。
2).数据访问层是独立的，它主要的作用是解释SQL语句。
系统把不同的功能放在不同的层次中，有绝对通用的，有在一定的业务范围内通用的，有在每个应用中都会有很大差异的业务层。
3).业务规则建成一个独立的层。
业务规则肯定是要建成一个独立的层，这样在开发下一个项目时，只要修改业务层的单元就可以。这个框架的一个作用就是所有的公
用单元在每个项目里都不需要变动。
5.数据字典建建成一个独立的表。
数据字典是系统中一个独立的可重用的对象，它至少会包含以下表：
数据表表：每条记录对应一个物理上数据表
字段表：为上述表中的字段，包括各字段的字段名、中文标题、显示格式、与其它表的关联方式等。 它主要是反映系统中的数据结构，
在通用查询中，如要筛选InventoryIn表，其中有字段fCustId，但客户不可能用fCustId来指定关于某单位的筛选条件，但借助数据字典，
系统可以查到fCustId是引用Cust表中的fId字段，而Cust表是一个基本资料表，它里面对用户而言可见的字段是编码、名称、类别、电话
号码等。这样的话，系统就可以在查询InventoryIn表时提供适当的界面，让用户可以输入单位编码或是单位名称来提供查询条件。而不
是把设定查询条件局限于InventoryIn表中直接可操作的对象，如日期、单号。
四、 近两年来，我们采软件生产线作业方式组装了几个有一定规模的产品：
如企业质检与物流管理、制造业综合管理系统等等。证明生产线可为软件公
司实现工业化低成本开发的组装作业方式。