进销存软件之OO设计

简介: 进销存软件之OO设计――中间层业务逻辑(一) 一 前言:   本文是作者本人的软件作品/产品 iSale商业进销存系统的部分设计思路,软件还在最后完善中,文中摘录这个软件中的部分设计思路和实现方法与网友共同讨论,以得到不同的意见,共同提高水平,   系统架构:可用于Internet的分布式多层(SocketConnection)系统   客户端:Delphi开发的客户端界面程序,Windows界面。

进销存软件之OO设计――中间层业务逻辑(一)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

一 前言:

 

本文是作者本人的软件作品/产品 iSale商业进销存系统的部分设计思路,软件还在最后完善中,文中摘录这个软件中的部分设计思路和实现方法与网友共同讨论,以得到不同的意见,共同提高水平,

 

系统架构:可用于Internet的分布式多层(SocketConnection)系统

 

客户端:Delphi开发的客户端界面程序,Windows界面。

中间层应用服务器:基于Delphi开发的DCOM组件(处理业务处理逻辑)

数据库服务器:Sql Server 2000数据库

 

 

二 参考图:

 

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

 img_3f5a85179763c11fac4757312870ff2b.jpg

 

 img_19ad9159e521f61ce93ed853cd31480a.jpg

  图2中层业务流

 

 

重要的类

图3:业务处理中3个重要的类

 

 


 

所有类图

图4:中间层所有的类

 

 

 

 

三 正文: 

一般情况下进销存系统一笔业务的实现往往是如下所示这样的(至少我的系统是这样做的)

 

操作员录单->>>>单据保存->>>>单据处理->>>>更新库存->>>>更新账务->>>>完成

 

上面的过程是一笔业务实现的大概轮廓,在实际当中可能比这个流程要复杂的多,比如要做一些权限检查,对于不同单据代表的不同业务类型,要用不同的处理办法进行更新库存更新账务的操作等。那么如何用面向对象的方法来抽象这个业务流程,这对于我个人来讲在几个月前是一个新的挑战,如今也算是实现出来,很是欣慰。下面我就中间层中对于业务处理的设计思路与大家分享,希望能得到宝贵意见。

 

多层分布式系统的应用服务器,用于控制系统业务的处理,DComCom+是应用服务器的外在表现,它们除了为客户端提供调用接口以及与向数据库服务器存取数据外,更重要的是我们可以将整个业务处理核心抽象成若干个类,这些类相互配合完成整个业务处理的流程,而这些类就存放于DcomCom+组件中(见图1中‘业务逻辑处理类’的位置)。〕

(读下文同时可参考上面图2)

 

TbizComponent类:

在图4中是系统中间层处理业务逻辑所用到的类,以及它们之间的关系,除了TbizProvider之外所有的类都是从TbizComponent继承(TbizComponent实际是继承自Tcomponent),这样做是为了提高扩展性,比如所有的TbizComponet的子类都需要某一个方法或属性实现一个功能时,只要在TbizComponet类加入此方法或属性就可以了,还可以在它的子类中Override方法来让子类有自已的实现。另外因为要在这些业务类中创建使用TadoQuery,而这些Tadoxxx类的Owner都要求是一个Tcomponent类或子类,所以这样就比较便于使用了。

 

TBaseBillobj类:

   注:以下文中提到的TxxxBillobj类代表各种业务单据处理子类 :TsaleBillobj, TbuyBillobj(TbaseBillobj外以Billobj结尾的类),见图4

进销存系统中录入不同单据代表不同业务发生,而无论哪种单据本身都有很多共同特点:新建单据、保存单据、更新单据,单据数据合法检查、单据状态控制等基本是每个单据要有的处理,因此可以抽象出一个TbaseBillobj基类(见图2,3)用于实现单据的基本操作。比如图4中TbaseBillobj就是所有TxxxBillobj的基类(中间TbizProcess提供过账处理接口见下文)。那么在图3中也可以看到TbaseBillobj类的细节,基中有些方法比如UpdateBill,SaveBill等都是在此基类中就已实现,由TxxxBillobj这些单据子类直接继承使用。但也有例外的情况,有些方法,比如OrderCheck是用于处理销售单和进货单相关联的销售订单和进货订单的完成状态的,只有销售单和进货单需要使用,那么在基类TbaseBillobj中就先将OrderCheck声明为Virtual方法,然后在基类中保持此方法的实现为空,如果是其它单据不必在单据子类override此方法,这样就会执行继承执行这个基类的空方法,如果是销售单和进货单则各自执行其Override后的方法。如下:

基类中声明:

procedure OrderCheck(cds:TClientDataSet); virtual;

 

基类中调用OrderCheck

procedure TBaseBillobj.BillDetailCheckData(cdsDataSet:TClientDataSet);

begin

  。。。。。。。

   {如果图4中的xxxBillobj单据子类没有override OrderCheck,那么在此实际上就会执行下面基类的的TbaseBillobj.OrderCheck,它是一个空方法。  } 

   if Self.FProcessTag>=2 then

     OrderCheck(cdsDataSet);

end;

基类实现:

procedure TBaseBillobj.OrderCheck(cds:TClientDataSet);

begin

  //只有销售单、进货单TsaleBillobjTbuyBillobj override并具体实现此方法

end;

  考虑一下,如果用非OO的设计来完成类似这样的情况,那应该是是写一个通用的OrderCheck然后用if判断来处理,实际上这里情况较简单,就销售单和进货单两种情况,如果是那种复杂情况if就会很多,那种程序不是很好维护而且总是用一种方式编程序也会很烦。

TbizProcess

  这个类是从TBaseBillobj继承下来的,如果说TBaseBillobj是用来处理业务单据的一般事务,那TbizProcess就是用来处理单据过账操作的,但是TBaseBillobj实际上只用几个Abstract Method来提供过账操作的接口而真正实现是由那些个TxxxBillobj的具体业务单据类来实现。请看下面讨论:

单据不仅要做保存更新这样的操作,还要有过账处理从而才能影响系统的库存和账务,最终才能从报表功能中表现这些影响,从而才能使用户得知当前业务的状况如何。基本上各单据的过账处理对账务的影响都是不同的,但大体可以归纳为钱流处理和物流处理,无论哪种单据最少都要执行这两个其中的一个,比如一张采购进货单处理后即会对系统钱流数据产生影响,而且对物流数据也产生影响,那么一张销货收款单只会对钱流数据产生影响,而销售订单即不会对钱流数据产生影响也不会对物流数据产生影响。于是对于不同的单据我们知道要进行钱流或物流的处理,但不知道具体单据类型之前,我们并不确定钱流或物流处理的具体内容,那么根据此特点,我们可以声明一个类TbizProcess(见图2,3),它有两个Abstract的方法:MoneyProcessGoodsProcess(见图3),代表钱流处理和物流处理的动作名称,之所以是‘动作名称’即这里只声明接口(我用的是Abstract Method做为接口而并非Interface),这样在具体单据处理子类的中实现这些Abstract Method后即可做‘具体动作’,另外PrepareProcessFinishProcess也是如此,分别在处理前和处理后做一些准备和善后工作。TbizProcess类还有一个方法是ProcessFlow,调用它来实现整个过账处理,无论是什么单据处理都是使用如下ProcessFlow

 

//业务单据过账处理:

function TBizProcess.ProcessFlow(BillHead:OleVariant; BillDetail:OleVariant; Tag:integer):

        Integer;

Begin

      。。。。。。。

      FConnection.BeginTrans;

。。。。。。。

。。。。。。。

        PrepareProcess;

        GoodsProcess;

        MoneyProcess;

        FinishProcess;

。。。。。。。

。。。。。。

      FConnection.CommitTrans;

      。。。。。。。

End;

这里以MoneyProcess为例:

 

进货单是这样的钱流处理

procedure TBuyBillobj.MoneyProcess;

begin

  with FBizProvider do

  begin

    BankProcess(-1); //现金银行账务处理

    ArApForBuy;    //应收应付账务处理

    StockGoods;     //库存成本账务处理(并非库存变动处理)

  end;

end;

收款单的钱流处理内容与进货单不相同,依此类推

procedure TGatheringBillobj.MoneyProcess;

begin

  with FBizProvider do

  begin

    BankProcess(1);

    ArApForGather;

  end;

end;

这样TbizProcess声明了接口(Abstract Method),那下层的单据子类如:TbuyBillobjTgatheringBillobj用统一接口实现不同操作内容。对于PrepareProcess; GoodsProcess;FinishProcess;也是一样的。这样无论子类的实现内容如何变化,调用程序都不被(或很少)受影响,因为有一至的接口。

注:可以用Abstract Method当做接口,但Interface更先进,特别是更复杂的情况下,VCL不少地方使用Abstract Method来当接口,但使用Interface好像是趋势(李维的<<Inside VCL>>中对Interface说明的相当的详细),另外看看.netframework,很多地方都使用Interface而不再是Abstract Method,特别是Ado.net。我使用Abstract Method的原因是当初的‘认识’问题以及系统并不巨大,而且当前所用的办法也工作的很好就是了。

 

TxxxBillobj类:

这是一系列具体单据处理类,xxx代表单据的英文名如TbuyBillobj,TsaleBillobj等,见图(4)。比如以下是销售单类的声明,它重新override了一些父类的方法以及实现了上面提到的4个抽象方法。其它TxxxBillobj的实现也都是基于这种思路。

 

  TSaleBillobj = class (TBizProcess)

  private

    FBizProvider: TBizProvider;

  public

    function BillHeadCondition: string; override;

    function DetailSql(optype:integer): string; override;

    procedure FinishProcess; override;

    procedure GoodsProcess; override;

    procedure MoneyProcess; override;

    procedure OrderCheck(cds:TClientDataSet); override;

    procedure PrepareProcess; override;

  end;

TbizProvider类:

  上面提到可以把业务流的处理分为MoneyProcessGoodsProcess,而钱流和物流处理实际上各自又包括一些具体内容,比如从上面进货单的钱流处理procedure TBuyBillobj.MoneyProcess;就可以看到总共有现金银行账务处理、应收应付账务处理、库存成本账务处理等,那么系统中像这些具体的处理功能有很多,用非OO的设计方法实现时可以写若干个通用的FunctionProcedure达到目的,如果用OO实现,我考虑了两种方法,一个是从父类声明Abstract Method(如果基类有实现可以用Virtual Method)方法,然后到子类再做具体实现。第二种是写一个服务类或者说是工具类比如就叫它TbizProvider类,它提供这些现金银行账务处理、应收应付账务处理、库存成本账务等处理的实现,然后各业务单据子类再声明一个此类型的属性或是域(我这里用的域FBizProvider)来使用。如下:

参考上面TsaleBillobj类的声明中 FBizProvider: TBizProvider;

TbizProvider的细节见图3,另外TbizProviderCreate如下:

声明:

constructor Create(AOwner:TComponent;BizObj:TBizProcess); reintroduce; overload;

实现:

constructor TBizProvider.Create(AOwner:TComponent;BizObj:TBaseBillObj);

begin

  inherited Create(AOwner);

  FBizObj:=BizObj;  

end;

这样TbizProviderCreate后将来就知道是为哪个业务单据做现金银行、应收应付等处理

如下为TsaleBillobj建立TbizProvider的实例:
procedure TSaleBillobj.PrepareProcess;

begin

  。。。。

FBizProvider:=TBizProvider.Create(Self,Self);

。。。。

end;

procedure TSaleBillobj.MoneyProcess;

begin

  with FBizProvider do         //调用TbizProvider提供的一系列功能

  begin

    BankProcess(1);

    ArApForSale;

    SaleCost;

    SaleIncome;

    StockGoods;

  end;

end;

以上TbizProviderCreate中第二个参数为TbaseBillObj类型的对象,而传入的实际为它的子类型(TSaleBillobj)对象实例(self),结合这样的处理方法正好也是OO中对多态的使用。(Overload那个Create与多态没有关系),这样一来,在TbizProvider内部只知道有一个要被提供服务的单据’(TbaseBillobj)就行了,具体是哪个单据(TxxxBillobj)不用知道,在TbizProvider的实现程序里使用那个FbizObj就可以了。

最后再看一下图4,可以看到各业务单据子类与TbizProvider建立了关联,这个关联是基于FbizProvider的。(图4是用ModelMaker反向工程出来的)

 

目录
相关文章
|
2月前
|
SQL 开发框架 .NET
OA办公自动化系统设计与实现(论文+源码)_kaic
OA办公自动化系统设计与实现(论文+源码)_kaic
|
2月前
|
监控 项目管理 调度
深入探究ERP系统的项目管理模块
深入探究ERP系统的项目管理模块
58 3
|
2月前
|
资源调度 供应链 监控
探索企业资源规划(ERP)系统的基本概念
探索企业资源规划(ERP)系统的基本概念
84 0
|
10月前
|
设计模式 数据采集 搜索推荐
趣解设计模式之《小王设计的疫苗管理平台系统》
趣解设计模式之《小王设计的疫苗管理平台系统》
49 0
|
数据挖掘
人力资源管理系统和oa的区别?
人力资源管理系统和OA系统都是企业常用的两款线上管理辅助工具,由于这两款系统的功能高度重合,常常被人们误以为是一个系统。但只要我们仔细去观察的话,这两款系统的功能和作用还是有很大的不同,而且从命名上人们把他们分为两个系统,也就证明这二者有着本质上的区别。下面就来详细介绍一下~
人力资源管理系统和oa的区别?
|
Java
java OA 办公系统 模块设计方案
java OA 办公系统 模块设计方案
185 0
java OA 办公系统 模块设计方案
|
SQL XML 监控
OA 系统源码模块设计方案
OA 系统源码模块设计方案
170 0
|
SQL XML 监控
JAVA oa 办公系统模块 设计方案
JAVA oa 办公系统模块 设计方案
180 0
OA系统模块设计方案
OA系统模块设计方案
141 0