CN101702125A - 一种零售业务的操作处理方法及装置 - Google Patents

Abstract

本发明涉及一种零售业务的操作处理方法及装置，所述方法包括：确定客户端发送的需要服务操作的服务类；根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类；对所述具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。所述装置包括：服务类确定单元、获取单元和操作处理单元。本发明以降低售后的维护工作量及用户的使用成本。

Description

一种零售业务的操作处理方法及装置

技术领域

本发明涉及业务处理技术，特别涉及一种零售业务的操作处理方法及装置。

背景技术

在现有的零售系统中，零售系统通常都需要外接各种外部设备，其中外部设备可以包括：条码扫描仪、RFID无线条码、磁卡读写设备、IC卡读写设备、电子秤等，并针对每种外部设备设计特定的接口，在零售系统的应用服务器中设定与该外部设备对应的应用程序，业务层调用不同外部设备的特定接口，为每种接口编写特定的业务功能代码，在该业务功能代码中需要包括与每种外部设备单独对应的底层代码，比如，在发放会员卡的功能界面上，点击写卡时，业务功能代码中要写具体的写卡底层代码；点击读卡时，业务功能代码中要写具体的读卡底层代码。再比如，在电子秤的业务功能代码里，也要嵌入电子秤的底层代码等。而在应用程序中，所述外部设备的业务代码和设备底层代码交叉在一起，一旦要增加、减少外部设备或者更改外部设备类型，都需要修改应用程序中的具体业务功能代码，并重新编译发布系统。从而给售后带来很大的维护工作量，并且需要客户额外出钱购买升级版本。

在对现有技术的研究和实践过程中，本发明的发明人发现，现有的实现方式中，当零售系统的外部设备发送增加、减少或外部设备的类型发生改变时，都需要修改应用程序中对应的具体业务功能代码，并重新编译发布系统，从而耗费大量的人力和物力，加大售后的维护工作，同时也增加客户的使用成本。

发明内容

本发明实施例提供一种零售业务的操作处理方法及装置，以降低售后的维护工作量及用户的使用成本。

为解决上述技术问题，本发明实施例提供一种零售业务的操作处理方法，

确定客户端发送的需要服务操作的服务类；

根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类；

对所述具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

可选的，所述根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类包括：

根据所述服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；

根据预设的配置文件确定所述设备服务所属的具体服务实现类。

可选的，所述根据所述服务类从预设的设备服务工厂类中获得对应的设备服务具体包括：

如果所述服务类为卡设备、电子秤设备、条码扫描设备或RFID设备，则通过设定的设备服务公共接口从预设的设备服务工厂类中获得对应厂商的卡设备类、电子秤设备类、条码扫描设备类或RFID设备类；

所述根据预设的配置文件确定所述设备服务所属的具体服务实现类具体包括：

如果配置文件中配置包括读写卡设备的配置，电子秤设备的配置、条码扫描设备的配置或RFID设备的配置，则确定所述读写卡设备的具体卡设备服务、具体电子秤服务、条码扫描设备的服务或RFID设备的服务。

可选的，所述方法还包括：

在应用服务器中预先建立设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类对应的具体服务实现类。

可选的，所述在应用服务器中建立设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类对应的具体服务实现类具体包括：

预先在应用服务器中定义设备服务工厂类；

确定需要服务的操作所属的服务类；

设置所述服务类对应的设备服务；

根据所述设备服务创建具体服务实现类，并将所述服务类对应的具体服务实现类通过设定的设备服务公共接口存储在定义的所述设备服务工厂类中。

可选的，所述方法还包括：

将所述服务类对应的具体服务实现类存储在lib文件中，所述lib文件存储在预设的配置文件中；

在所述需要服务操作的服务类更新时，对预设的配置文件的lib文件中对应的具体服务实现类进行更新。

相应的，本发明还提供一种零售业务的操作处理装置，包括：

服务类确定单元，用于确定客户端发送的需要服务操作的服务类；

获取单元，用于根据预设的配置文件从设备服务工厂类中获得所述服务类对应的具体服务实现类；

操作处理单元，用于对所述获取单元获得的具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

可选的，所述获取单元包括：

设备服务获得单元，用于根据所述服务类确定单元确定的服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；

具体服务实现类确定单元，用于根据预设的配置文件确定所述设备服务所属的具体服务实现类。

可选的，所述装置还包括：

工厂类建立单元，用于预先定义设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类及其对应的具体服务实现类。

可选的，所述工厂类建立单元具体包括：

定义单元，用于在应用服务器中定义设备服务工厂类；

预先确定单元，用于预先确定需要服务的操作所属的服务类；

服务设置单元，用于根据所述预先确定单元确定的所述服务类设置对应的设备服务；

具体服务创建单元，用于根据所述服务设置单元设置的设备服务创建具体服务实现类，并通过设定的设备服务公共接口将所述服务类及对应的具体服务实现类存储在所述定义单元设定的设备服务工厂类中。

可选的，所述装置还包括：

存储单元，用于将所述获取单元获取的服务类，及所述服务类对应的具体服务实现类存储在lib文件中，并将所述lib文件存储在预设的配置文件中；

配置文件更新单元，用于在所述服务类确定单元确定需要服务操作的服务类更新时，对所述存储单元中预设的配置文件的lib文件中服务类及所述服务类对应的具体服务实现类进行更新。

可选的，所述零售业务的处理装置集成在应用服务器中，或者独立部署。

由上述实施例可知，在本发明中，根据零售系统对卡设备、条码扫描、电子秤等外部设备的读取等各种操作，设计一个公共的设备服务的操作接口(即设备服务公共接口)。使得零售系统可以屏蔽各种外部设备的底层接口细节(比如底层代码)，统一定义所有外部设备的公共接口，使得业务层(比如应用服务器)直接调用这个统一公共接口来操作不同的外部设备，从而简化了系统的配置和业务层调用技术，另外，当有新的外部设备需要加入该零售系统时，可以通过更新预设的配置文件的配置，即在该配置文件中添加该外部设备的服务类及其对应的具体服务实现类，从而降低了售后的维护工作量及用户的使用成本。

附图说明

图1为本发明中提供的一种零售业务的操作处理方法的流程图；

图2为本发明中提供的一种零售业务的操作处理方法另一流程图；

图3为本发明中提供的一种零售业务的操作处理方法的一种应用实例图；

图4为本发明中提供的一种零售业务的操作处理装置的结构示意图。

具体实施方式

下面我们将结合附图，对本发明的实施方案进行详细描述。

请参阅图1，为本发明中提供的一种零售业务的操作处理方法的流程图，所述方法包括：

步骤101：确定客户端发送的需要服务操作的服务类；

步骤102：根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类；

步骤103：对所述具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

可选的，步骤102具体可以包括：根据所述服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；比如，如果所述服务类为卡设备、电子秤设备、条码扫描设备或RFID设备，则通过设定的设备服务公共接口从预设的设备服务工厂类中获得对应厂商的卡设备类、电子秤设备类、条码扫描设备类或RFID设备类；

根据预设的配置文件确定所述设备服务所属的具体服务实现类。比如，如果配置文件中配置包括读写卡设备的配置，电子秤设备的配置、条码扫描设备的配置或RFID设备的配置，则确定所述读写卡设备的具体卡设备服务、具体电子秤服务、条码扫描设备的服务或RFID设备的服务。

其中，设定的设备服务公共接口(IDeviceService)为抽取统一的设备接口，对业务层屏蔽不同设备接口底层的差异。使得业务层(UI)只需调用设备服务公共接口来操作不同的设备(比如，读写卡器、电子秤、条码扫描、RFID等等)。

本发明中，抽取各种设备的设备服务公共接口的操作方法可以为：读(read)、写(write)、初始化(init)、关闭(close)。每种设备的各种操作，都能归纳到这四类中，只是参数、结果不同。

因此，本发明定义一个IDeviceService的统一设备服务类，这个类提供四个方法。每个方法传入一个参数类(CardDeviceInfo)，返回一个结果类(CardDeviceResult)。不同设备可以在参数类中动态设置各种参数值，在结果类中设置各自的结果信息。下面以卡设备为例，

对于读方法：CardDeviceResult read(Param CardDeviceInfo)

对于写方法：CardDeviceResult write(Param CardDeviceInfo)

对于初始化方法：CardDeviceResult init(Param CardDeviceInfo)

对于关闭方法：CardDeviceResult close(Param CardDeviceInfo)

由此可知，具体的业务功能程序，只需要通过一个设备服务工厂类根据预设的配置文件构造出一个具体的IDeviceService类。然后调用这个类的读、写、初始化、关闭方法既可。

就不用每个业务功能程序都自己去实现不同设备的底层代码，每种设备的底层代码，都封装在各自对IDeviceService类的具体实现类里面。作为系统出厂可选择的lib包。使用者可以在配置文件中指定具体的IDeviceService实现类和设备类型。

可选的，所述方法还可以包括：在应用服务器中预先建立设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类对应的具体服务实现类；具体可以包括：预先在应用服务器中定义设备服务工厂类；确定需要服务的操作所属的服务类；设置所述服务类对应的设备服务；根据所述设备服务创建具体服务实现类，并将所述服务类对应的具体服务实现类通过设定的设备服务公共接口存储在定义的所述设备服务工厂类中。

可选的，所述方法还可以包括：将所述服务类对应的具体服务实现类存储在lib文件中，所述lib文件存储在预设的配置文件中；在所述需要服务操作的服务类更新时，对预设的配置文件的lib文件中对应的具体服务实现类进行更新。

在本发明中，根据零售系统对卡设备、条码扫描、电子秤等外部设备的读取等各种操作，设计一个公共的设备服务的操作接口(即设备服务公共接口)。使得零售系统可以屏蔽各种外部设备的底层接口细节(比如底层代码)，统一定义所有外部设备的公共接口，使得业务层(比如应用服务器)直接调用这个统一公共接口来操作不同的外部设备，从而简化了系统的配置和业务层调用技术，另外，当有新的外部设备需要加入该零售系统时，可以通过更新预设的配置文件的配置，即在该配置文件中添加该外部设备的服务类及其对应的具体服务实现类，从而降低了售后的维护工作量及用户的使用成本。

还请参阅图2为本发明提供一种零售业务的操作处理方法的一种应用实例的流程图，在该实施例中，先定义一个设备服务公共接口(比如读、写等)，通过该设备服务公共接口为不同的外部设备开发具体的服务实现类，调用设备底层处理方法，业务层(比如操作界面)，调用设备服务公共接口，来访问不同的外部设备对应的具体的服务实现类。当有新的外部设备增加时，业务层(界面)不需要进行相应的处理、通过设备服务公共接口仍然可以调用设备底层方法。

在该实施例中，外部设备以卡设备为例，但并不限于此，其他外部设备的实现过程类似，其具体的实现过程包括：

步骤201：应用服务器(比如应用程序RtCardBilEditUI)调用设备操作功能类(CardDeivceUtil)的获取设备服务类；其具体的实现过程详见图3中标号为(1)至(3)的步骤，所述图3为图2的具体流程图，下同。

在该图3中，(1)用户读卡设备，即用户打开卡单据；(2)卡单据在卡读写界面上显示；(3)卡读写界面调用卡功能类(CardDeviceUtil)的方法创建卡服务类(CardServer)。

步骤202：设备操作功能类(CardDeviceUtil通过设备服务工厂类(DeviceSerivceFactory)获得设备服务(DeviceService)；

在该步骤中，设备服务(DeviceService)根据预设配置的文件创建具体设备的驱动类；如果配置的是卡设备，就创建具体厂商的卡设备类；如果配置的是电子秤，就创建具体的电子秤设备类，其他外部设备类似，在此不再一一描述。所述这些外部设备类会调用具体的底层DLL的API。其具体的调用过程为本领域公知技术，在此不在赘述。

因此，在该步骤中，就屏蔽了具体外部设备的不同底层DLL的API。简化了应用系统调用外部设备的复杂性。

该步骤的具体实现过程的应用实例，详见图3中标号为(4)的步骤，即(4)卡功能类(CardDeviceUtil)调用卡服务工厂类(CardDeviceFactory)创建卡服务类(CardServer)；

步骤203：设备服务工厂类(DeviceSerivceFactory)根据预设的配置文件，创建具体设备服务。如果，配置的是读写卡设备，就创建具体的卡设备服务；如果配置的是电子秤，就创建具体的电子秤服务，但并不限于此，也可以其他的外部设备，在此不在赘述。

该步骤的具体实现过程的应用实例，详见图3中标号为(5)至(7)，即：(5)工程类读取配置文件；(6)跟进配置文件创建具体设备服务；(7)返回所创建的设备服务；

步骤204：应用服务器(如应用程序RtCardBilEditUI)调用设备操作功能类(CardDeivceUtil)的读写等操作，该步骤的具体应用实例详见图3中标号为(8)的步骤，即(8)应用程序调用卡功能类(CardDeivceUtil)的读写；

步骤205：卡功能类(CardDeivceUtil)调用设备服务(DeviceService)的具体读写等操作，该步骤的具体应用实例详见图3中标号为(9)和⑩的步骤，即(9)卡功能类(CardDeivceUtil)设置设备服务(DeviceService)的参数；(10)CardDeivceUtil调用设备服务(DeviceService)的具体读写等操作方法；

步骤206：设备服务(DeviceService)调用设备服务(DeviceService)，即调用具体设备的驱动类调用设备；该步骤的具体应用实例详见图3中标号为(11)的步骤，即(11)卡功能类(CardDeivceUtil)设置设备服务(DeviceService)的参数；

步骤207：应用服务器(如应用程序RtCardBilEditUI)获得操作结果。该步骤的具体应用实例详见图3中标号为(12)至(14)的步骤，即(11)底层程序返回操作结果；(12)卡服务类返回操作结果；(13)卡服务工具类返回操作结果；(14)卡读写界面返回操作结果给卡单据。

需要说明的是，在图3中的步骤15和27的具体为写卡设备的具体实现过程，其过程与读卡设备的实现过程，只需要读卡设备的步骤(1)至(15)中的“读”替换为“写”即可，同时，在该写卡设备的实现过程中没有步骤(5)，具体详见图3中的步骤(15)至(27)。

基于上述方法的实现过程，本发明还提供一种零售业务的操作处理装置，其结构示意图详见图4，所述装置包括：服务类确定单元41、获取单元42和操作处理单元43，其中，所述服务类确定单元41，用于确定客户端发送的需要服务操作的服务类；所述获取单元42，用于根据预设的配置文件从设备服务工厂类中获得所述服务类对应的具体服务实现类；所述操作处理单元43，用于对所述获取单元42获得的具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

可选的，所述获取单元包括：设备服务获得单元和具体服务实现类确定单元，其中，所述设备服务获得单元，用于根据所述服务类确定单元确定的服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；所述具体服务实现类确定单元，用于根据预设的配置文件确定所述设备服务所属的具体服务实现类。

可选的，所述装置还包括：工厂类建立单元，用于预先定义设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类及其对应的具体服务实现类。

其中，所述工厂类建立单元具体包括：定义单元、预先确定单元和服务设置单元，其中，所述定义单元，用于在应用服务器中定义设备服务工厂类；所述预先确定单元，用于预先确定需要服务的操作所属的服务类；所述服务设置单元，用于根据所述预先确定单元确定的所述服务类设置对应的设备服务；所述具体服务创建单元，用于根据所述服务设置单元设置的设备服务创建具体服务实现类，并通过设定的设备服务公共接口将所述服务类及对应的具体服务实现类存储在所述定义单元设定的设备服务工厂类中。

可选的，所述装置还可以包括：存储单元和配置文件更新单元，其中，所述存储单元，用于将所述获取单元获取的服务类，及所述服务类对应的具体服务实现类存储在lib文件中，并将所述lib文件存储在预设的配置文件中；所述配置文件更新单元，用于在所述服务类确定单元确定需要服务操作的服务类更新时，对所述存储单元中预设的配置文件的lib文件中服务类及所述服务类对应的具体服务实现类进行更新。

可选的，所述零售业务的处理装置可以集成在应用服务器中，或者独立部署，本实施例不作限制。

在本发明中，根据零售系统对卡设备、条码扫描、电子秤等外部设备的读取等各种操作，设计一个公共的设备服务的操作接口(即设备服务公共接口)。使得零售系统可以屏蔽各种外部设备的底层接口细节(比如底层代码)，统一定义所有外部设备的公共接口，使得业务层(比如应用服务器)直接调用这个统一公共接口来操作不同的外部设备，从而简化了系统的配置和业务层调用技术，另外，当有新的外部设备需要加入该零售系统时，可以通过更新预设的配置文件的配置，即在该配置文件中添加该外部设备的服务类及其对应的具体服务实现类，从而降低了售后的维护工作量及用户的使用成本。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (12)

1.一种零售业务的操作处理方法，其特征在于，包括：

确定客户端发送的需要服务操作的服务类；

根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类；

对所述具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

2.根据权利要求1所述的方法，其特征在于，所述根据预设的配置文件从设备服务工厂类中确定所述服务类对应的具体服务实现类包括：

根据所述服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；

根据预设的配置文件确定所述设备服务所属的具体服务实现类。

3.根据权利要求2所述的方法，其特征在于，

所述根据所述服务类从预设的设备服务工厂类中获得对应的设备服务具体包括：

如果所述服务类为卡设备、电子秤设备、条码扫描设备或RFID设备，则通过设定的设备服务公共接口从预设的设备服务工厂类中获得对应厂商的卡设备类、电子秤设备类、条码扫描设备类或RFID设备类；

所述根据预设的配置文件确定所述设备服务所属的具体服务实现类具体包括：

如果配置文件中配置包括读写卡设备的配置，电子秤设备的配置、条码扫描设备的配置或RFID设备的配置，则确定所述读写卡设备的具体卡设备服务、具体电子秤服务、条码扫描设备的服务或RFID设备的服务。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

在应用服务器中预先建立设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类对应的具体服务实现类。

5.根据权利要求4所述的方法，其特征在于，所述在应用服务器中建立设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类对应的具体服务实现类具体包括：

预先在应用服务器中定义设备服务工厂类；

确定需要服务的操作所属的服务类；

设置所述服务类对应的设备服务；

根据所述设备服务创建具体服务实现类，并将所述服务类对应的具体服务实现类通过设定的设备服务公共接口存储在定义的所述设备服务工厂类中。

6.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

将所述服务类对应的具体服务实现类存储在lib文件中，所述lib文件存储在预设的配置文件中；

在所述需要服务操作的服务类更新时，对预设的配置文件的lib文件中对应的具体服务实现类进行更新。

7.一种零售业务的操作处理装置，其特征在于，包括：

服务类确定单元，用于确定客户端发送的需要服务操作的服务类；

获取单元，用于根据预设的配置文件从设备服务工厂类中获得所述服务类对应的具体服务实现类；

操作处理单元，用于对所述获取单元获得的具体服务实现类进行操作处理，得到操作处理的结果，并通过所述客户端显示所述操作处理的结果。

8.根据权利要求7所述的装置，其特征在于，所述获取单元包括：

设备服务获得单元，用于根据所述服务类确定单元确定的服务类通过设定的设备服务公共接口从设备服务工厂类中获得对应的设备服务；

具体服务实现类确定单元，用于根据预设的配置文件确定所述设备服务所属的具体服务实现类。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

工厂类建立单元，用于预先定义设备服务工厂类，并通过设定的设备服务公共接口在所述设备服务工厂类中存储服务类及其对应的具体服务实现类。

10.根据权利要求9所述的装置，其特征在于，所述工厂类建立单元具体包括：

定义单元，用于在应用服务器中定义设备服务工厂类；

预先确定单元，用于预先确定需要服务的操作所属的服务类；

服务设置单元，用于根据所述预先确定单元确定的所述服务类设置对应的设备服务；

具体服务创建单元，用于根据所述服务设置单元设置的设备服务创建具体服务实现类，并通过设定的设备服务公共接口将所述服务类及对应的具体服务实现类存储在所述定义单元设定的设备服务工厂类中。

11.根据权利要求7所述的装置，其特征在于，所述装置还包括：

存储单元，用于将所述获取单元获取的服务类，及所述服务类对应的具体服务实现类存储在lib文件中，并将所述lib文件存储在预设的配置文件中；

配置文件更新单元，用于在所述服务类确定单元确定需要服务操作的服务类更新时，对所述存储单元中预设的配置文件的lib文件中服务类及所述服务类对应的具体服务实现类进行更新。

12.根据权利要求7至11任一项所述的装置，其特征在于，所述零售业务的处理装置集成在应用服务器中，或者独立部署。

Images