一种基于事件驱动的组件方法与流程

本发明涉及到计算机软件开发的技术领域，尤其涉及到一种基于事件驱动的组件方法。

背景技术：

传统的模块间方法直接调用式开发，软件领域中，如果是传统软件开发方法，在已有的模块模块中，如果增加新功能，则需要直接改动相应的模块的代码，造成对现有功能直接性的破坏，导致原有功能不稳定。另外，在传统的软件开发方法中，如果新增的功能的逻辑在其它模块需要重复使用，则只能通过copy代码或方法调用的方式来重用，还是需要改动原代码。

技术实现要素：

本发明的目的是为了克服现有技术的不足，提供了一种基于事件驱动的组件方法。

本发明是通过以下技术方案实现：

本发明提供了一种基于事件驱动的组件方法，该基于事件驱动的组件方法包括：在软件的业务模块中抽象出核心业务逻辑及核心业务数据；

抽象出所述核心业务逻辑相对应的事件接口；

将所述业务模块中除去核心业务数据外的业务为组件，所述组件是由一组业务插件组成的，所述插件是一个或多个核心业务的事件的实现体；

在组件描述文件中定义不同的业务插件与核心业务逻辑之间的关联关系，所述业务插件与所述核心业务逻辑之间的关联通过插件桩收集起来；

所述核心业务逻辑根据所述插件桩收集起来的关联找到对应的业务插件。

优选的，将所述业务模块中除去核心业务数据外的业务根据设定的条件划分成不同的业务插件，不同的业务插件形成一组业务插件组具体为：

查找所有的组件描述文件，并解析出业务插件与核心业务逻辑之间的关联关系；

将业务插件与核心业务逻辑之间的关系通过组件视图记录到内存中；

检测业务插件安装情况，检测数据中是否有此业务插件，若组件视图中没有记录，则在数据中记录，并且该业务插件被标记为未安装、未启动，如果数据中已经存在所述业务插件，则显示已经启动。

优选的，所述核心业务逻辑根据所述插件桩收集起来的关联找到对应的业务插件具体为：

在软件在软件运行中，当核心业务逻辑被调用的同时调用事件接口，同时向接口传递核心业务数据，这个过程被称为事件激发，当事件激时，插件桩里已经收集了相应的业务插件集合，进而在插件桩中一个个的调用业务插件，传递核心数据，这样业务插件被执行。

本发明的有益效果是：通过上述组件的方法，可以实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就可以完成对核心业务的扩展，开发效率高、重用性高。

附图说明

图1是本发明实施例提供的基于事件驱动的组件方法核心业务与组件之间的关系图；

图2是本发明中的业务插件家在过程的示意图；

图3是本发明中的业务插件的调用示意图；

图4是本发明实施例提供的基于事件驱动的组件方法流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例提供了一种基于事件驱动的组件方法，该基于事件驱动的组件方法包括：在软件的业务模块中抽象出核心业务逻辑及核心业务数据；

抽象出所述核心业务逻辑相对应的事件接口；

将所述业务模块中除去核心业务数据外的业务为组件，所述组件是由一组业务插件组成的，所述插件是一个或多个核心业务的事件的实现体；

在组件描述文件中定义不同的业务插件与核心业务逻辑之间的关联关系，所述业务插件与所述核心业务逻辑之间的关联通过插件桩收集起来；

所述核心业务逻辑根据所述插件桩收集起来的关联找到对应的业务插件。

其中的，将所述业务模块中除去核心业务数据外的业务根据设定的条件划分成不同的业务插件，不同的业务插件形成一组业务插件组具体为：

查找所有的组件描述文件，并解析出业务插件与核心业务逻辑之间的关联关系；

将业务插件与核心业务逻辑之间的关系通过组件视图记录到内存中；

检测业务插件安装情况，检测数据中是否有此业务插件，若组件视图中没有记录，则在数据中记录，并且该业务插件被标记为未安装、未启动，如果数据中已经存在所述业务插件，则显示已经启动。

此外，所述核心业务逻辑根据所述插件桩收集起来的关联找到对应的业务插件具体为：

在软件在软件运行中，当核心业务逻辑被调用的同时调用事件接口，同时向接口传递核心业务数据，这个过程被称为事件激发，当事件激时，插件桩里已经收集了相应的业务插件集合，进而在插件桩中一个个的调用业务插件，传递核心数据，这样业务插件被执行。

在上述实施例中，通过上述组件的方法，可以实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就可以完成对核心业务的扩展，开发效率高、重用性高。

为了方便理解本实施例提供的方法，下面结合具体的实施例进行详细说明。

首先，相关概念抽像及定义

在软件的业务模块中抽像出核心业务逻辑(Core Service)及核心业务数据(Core Data Model)，同时抽像出核心业务逻辑相对应的事件接口(Event Interface)。

在核心业务之外的业务被称之为组件(Component)，组件是由一组业务插件(Plugin)组成的，这些插件是一个或多个核心业务的事件的实现体，核心业务和事件的关联，是通过插件桩(Plugin Bundle)收集起来的，具体的关联关系是在一个名为Component.xml(组件描述文件)中定义的。其中核心业务与组件之间的关系如图1所示。

组件的开发

当需要在核心业务逻辑中插入新的逻辑时，需要定义出相应的插件，使插件实现相应的业务事件接口，在插件中实现具体业务逻辑代码，其需要的核心业务数据会通过事件接口做为参数传递过来，这样插件就可以无入侵式的操作核心业务数据了。

组件的加载和启动

首先组件有以下状态：安装状态和启动状态，分别为已安装和未安装，已启动和未启动。

当系统启动时，组件加载模块查找所有的Component.xml，并解析出插件和核心业务的关联关系，并将这种关系通过组件视图(Component View)记录在内存中。

在加载过程中，检测数据中是否有此组件的记录，如果没有则在数据中记录，此时组件的状态被标记为未安装、未启动。如果数据库中已经存在则检测其状态，如果是已启动状态，则将此组件启动，并标记为已启动状态。其加载过程如图2所示，

在系统的控制台中展示组件的列表，并提供操作按钮，可以执行以下操作：安装/卸载、启动/停用。

综上所述，组件被启动可能通过两种途径：系统加载时或在控制台中手动启动。组件被启动后，根据组件视图中记录的关系将插件和插件桩进行关系绑定，即将插件动态插入到插件桩中，即完成业务逻辑动态地、无侵入式地插入到核心业务逻辑中。

插件调用逻辑说明，整个的调用插件过程如图3所示。

在软件运行中，当核心业务逻辑被调用的同时调用事件接口，同时向接口传递核心业务数据，这个过程被称为事件激发。

当事件激时，插件桩里已经收集了相应的插件集合(事件的实现体)，进而在插件桩中一个个的调用插件，传递核心数据，这样插件被执行。

通过上述组件的技术方案，可以实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就可以完成对核心业务的扩展，开发效率高、重用性高。

效果举例：以电子商务系统为例，在一个电商业务中创建订单是核心的业务逻辑，在订单创建成功后，可能需要发送一条手机短信给顾客，基于此种组件方案，开发人员需要开发一款基于某个电信网关的短信发送组件。开发人员不必了解订单创建的具体代码，只需关心如何跟电信网关对接即可，组件机制会将订单信息、顾客手机号等核心数据通过订单的创建事件传递给插件，插件拿到上述数据，根据具体接入的电信网关参数，将核心数据(订单信息、顾客手机号)组织好文字，传递给电信网关就完成了通过此短信网关发送订单短信的功能。

一旦业务发生变更，比如要更换其它短信网关发送短信，此时再根据具体的网关参数开发另一款短信组件，然后停用之前的短信组件，安装上新的组件即可，整个流程如图4所示。

可以看出，从功能开发，到后期的变更维护，订单创建的核心业务代码从未暴露给组件开发人员，他们也不需要去改动核心代码，保持了原有系统的稳定性，降低了新功能开发的难度，而且基于同样规则的系统都可以安装此短信组件，直接使用，极大的降低了开发成本。

实施例一：订单业务组件化及订单短信组件

下面以电子商务系统中的核心逻辑：“订单创建”，以“订单短信组件”为例来说明具体的技术实施。

此专利方案绝不局限在电子商务或订单逻辑中，本专利方案适用于各种软件系统及各个业务领域中，比如在CMS系统、OA系统、ERP系统中均可以采用此专利技术方案，本技术方案无行业领域的局限性。

本实施例以Java开发语言为例说明方案，但绝不仅限此开发语言实现，其它开发语言均可实现此技术方案，如C#/.Net、Php、Ruby、C++等，本技术方案无开发语言局限性。

1.订单核心业务(OrderService)

负责订单的创建，这属于电商业务的核心，通过createOrder()方法创建订单。

2.订单插件桩(OrderPluginBundle)

在其pluginList属性中存储了所有响应订单业务事件的插件。

3.订单创建事件接口(OrderCreateEvent)

订在订单创建成功后，会激发此事件，而实际调用的是上述pluginList中的插件。

组件的组成

订单短信组件由以下内容：

订单短信组件(OrderSmsComponent)

订单组件类，在组件被安装时会调用其install方法，完成一些安装必要的操作。

订单短信插件

此类实现了订单创建事件，响应了订单完成事件(onOrderCreate)方法，当订单创建完成时，会调用此方法。

组件的描述文件Component.xml

此描述文件定义了订单插件(OrderSmsPlugin)要注入到订单插件桩中，即定义了插件要对应的核心业务

事件激发及插件调用

具体技术实施细节如下：

在这里循环所有的订单创建事件调用之(激发事件接口)，这些事件实际是被注入进来的、具体的插件实现体，比如订单短信插件，此时订单短信插件被动态调用，在此插件中完成发送短信的逻辑。

实施例二：红酒商品酒庄属性组件

下面以电子商务软件领域中商品数据保存为例，介绍红酒类商品的酒庄属性组件化来说明具体的技术实施。

此专利方案绝不局限在电子商务或订单逻辑中，本专利方案适用于各种软件系统及各个业务领域中，比如在CMS系统、OA系统、ERP系统中均可以采用此专利技术方案，本技术方案无行业领域的局限性。

本实施例以Java开发语言为例说明方案，但绝不仅限此开发语言实现，其它开发语言均可实现此技术方案，如C#/.Net、Php、Ruby、C++等，本技术方案无开发语言局限性。

在一般的电商业务中，商品主要由详细描述和相册构成，详细描述定义商品的名称、价格等基本信息，相册定义商品的图片信息。

本实施例通过组件的方式，实现了某款红酒其酒庄信息的维护，无需要改动核心业务代码。

其中，商品保存核心业务

1.订单核心业务(GoodsService)

负责商品的保存，这属于电商业务的核心，通过addGoods()方法添加商品。

2.订单插件桩(GoodsPluginBundle)

在其pluginList属性中存储了所有响应商品业务事件的插件。

3.商品添加事件接口(GoodsAddEvent)

订在订单创建成功后，会激发此事件，而实际调用的是上述pluginList中的插件。

酒庄商品组件

酒庄组件由以下内容：

酒庄组件(ChateauComponent)

酒庄组件类，在组件被安装时会调用其install方法，完成一些安装必要的操作。

酒庄插件

此类实现了商品添加事件，响应了商品创建事件(onAddGoods)方法，当商品添加时，会调用此方法。

组件的描述文件Component.xml

此描述文件定义了酒庄插件(ChateauPlugin)要注入到商品插件桩中，即定义了插件要对应的核心业务

事件激发及插件调用

具体技术实施细节如下：

在这里循环所有的商品添加事件调用之(激发事件接口)，这些事件实际是被注入进来的、具体的插件实现体，也就是上述的酒庄插件，此时酒庄插件被动态调用，在此插件中完成酒庄信息和酒品关系保存的逻辑。

通过上述具体的实施例可以看出，通过上述组件的方法，可以实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就可以完成对核心业务的扩展，开发效率高、重用性高。

以上仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。