进销存软件之OO设计――中间层业务逻辑(一)

转载 2006年06月26日 13:13:00

一 前言:

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

另外我本人将在2004年2月末-3月份期间寻找工作机会(即软件1.0完成后),如有伯乐请Email: cocoboy79 (at) 163.comqq:364941

文中提到的技术等相关内容仅供参考,如有不妥之处请告之,谢谢合作。

 

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

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

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

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

 

二 参考图:

  系统架构图

                                  图1系统架构图

业务流程及类对应图

                    图2 业务流程及类对应图

                                 图3 重要的类

                     图4 所有类及关系

                

图4说明:

Tlogon:处理登录,权限检查

TbaseInfo:系统基本信息处理

TqueryObj:系统查询功能处理

TbaseBillObj:系统单据处理基类

TbillDataCopy:缓存单据数据

TbizProcess:业务处理类,提供业务处理接口

TbizProvider:具体业务处理功能实现的工具集

TxxxBillobj:各种业务单据处理子类 :TsaleBillobj, TbuyBillobj等。

 

三 正文:

 

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

 

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

 

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

 

多层分布式系统的应用服务器,用于控制系统业务的处理,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就会很多,那种程序不是很好维护而且总是用一种方式编程序也会很烦。

 

 

     由于篇幅所限,更多内容在 进销存软件之OO设计--中间层处理(二)

软件架构设计系列总结—6—业务逻辑层简述

业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创...

基于命令模式的业务逻辑层设计

基于命令模式的业务逻辑层设计问题   1.业务发展太快,需求不停的在变   目前作的业务系统业务逻辑非常复杂,网站承载的用户访问量也在逐渐增大,更要命的是需求的不确定性,天天都有新需求,每次的改动量都...

业务逻辑层的设计(四)——表模块模式简介

其实我觉得写博文也可以跟写小说一样,有连载,只要读得顺畅就好,我并不想通过几篇博文读下来,就让读者成为某个方面的专家。 在每写一篇短短的博文,都曾参考过很多有价值的书籍和其他人的博文,所以不可能把所...

hjr学习-设计模式:业务逻辑层

数据持久化想要软件或系统重启后不丢失的数据需要做数据持久化,可以保存到数据库、文件等里面。数据持久化一般有两种: - DBHelper:这种比较经典,就是写一个类专门负责数据库各种操作,比如增删改...
  • hjrcrj
  • hjrcrj
  • 2016年11月09日 22:31
  • 186

petshop4.0 详解之五(PetShop之业务逻辑层设计)

业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统 所应对...

设计模式之 抽象工厂 封装业务逻辑层和Dao层

一般情况下软件应该尽量遵循以下的设计原则: 开闭原则(OCP)   对扩展开放,对修改关闭 里氏替换原则(LSP)   任何类出现的地方,子类一定可以出现(is-a) 依赖倒转...
  • judyge
  • judyge
  • 2015年11月18日 19:30
  • 436
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:进销存软件之OO设计――中间层业务逻辑(一)
举报原因:
原因补充:

(最多只允许输入30个字)