CN107291563A - 一种后端代码插件的调用方法和装置 - Google Patents

Abstract

本发明涉及一种后端代码插件的调用方法和装置，其中所述调用方法包括判断插件路由是否接收到插件调用请求；若插件路由接收到插件调用请求，判断所述调用请求是否合法；若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型；调用插件入口方法以获取相应的插件执行结果；将所述插件执行结果转换成特定参数类型。本发明能够实现插件的独立性，同时还能使得代码插件能够灵活的组合应用，降低耦合，提升插件的开发使用效率。

Description

一种后端代码插件的调用方法和装置

技术领域

本发明涉及计算机软件开发领域，尤其涉及一种后端代码插件的调用方法和装置。

背景技术

.NET是基于互联网的跨语言软件开发平台，顺应了当今软件工业分布式计算、面向组件、企业级应用、软件服务化和以Web为中心等大趋势。在现有的.NET上的Web应用开发领域，如果想进行代码的“动态加载”，一般会采用流行的第三方IoC框架，其动态加载原理一般使用反射或者Emit等技术，来通过XML配置文件，加载实现了目标接口的DLL文件，此种模式下，针对各个模块与功能，要求先定义各自的接口，然后按不同的业务力度来简历多个实现了这些接口的实例项目，以便编译成不同的DLL。但是不同的IOC框架开发风格不尽相同，并且需要额外理解较为复杂的第三方框架配置，而且也不利于版本的快速迭代，灵活性差，尤其是无法解决.NET上Web应用站点默认整站打包的情况。

而后端代码插件化技术(Ucsmy.CodePlugIn)能够灵活高效地增加Web后端能力，并且尽可能降低风险，并以尽可能小的粒度灵活划分模块与功能，同时在增加、修改、删除Web应用上的某个模块或者功能，都仅仅只会影响到所涉及的模块或功能“自身”，减少甚至消减由于版本更新迭代而引发的对其他模块或者功能的影响，故针对后端代码的插件化，需要提供一种关于后端代码插件的调用方法，以实现上述功能。

发明内容

针对现有技术的不足，本发明的目的旨在于提供一种后端代码插件的调用方法和装置，能够在基于.NET框架的条件下实现插件的独立性，同时还能使得代码插件能够灵活的组合应用，降低耦合，提升插件的开发使用效率。

为实现上述目的，一方面，本发明提供一种后端代码插件的调用方法，包括如下步骤，

判断插件路由是否接收到插件调用请求；

若插件路由接收到插件调用请求，判断所述调用请求是否合法；

若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型；

调用插件入口方法以获取相应的插件执行结果；

将所述插件执行结果转换成特定参数类型。

作为优选的，所述加载插件文件并将所述插件文件转换为插件类型的步骤之前还包括，

根据调用方的配置数据判断调用方是否有调用权限；

其中，若所述调用方有调用权限，则执行所述加载插件文件并将所述插件文件转换为插件类型的步骤。

作为优选的，所述将所述插件执行结果转换成特定参数类型的步骤之后还包括，

记录符合预设条件的插件并生成调用方访问日志。

作为优选的，所述判断所述调用请求是否合法包括，

根据所述调用请求获取插件配置数据；

判断所述插件配置数据与第一预设数据是否相同。

作为优选的，所述加载插件文件并将所述插件文件转换为插件类型包括，

根据所述调用请求获取插件编号；

根据所述插件编号确定所述插件路由中的插件安装路径；

根据所述插件安装路径定位并加载相关的插件文件；

将所述插件文件转换为插件类型。

另一方面，本发明还提供一种装置，包括，

存储器，用于存储程序指令；

处理器，用于运行所述程序指令，以执行以下步骤，

判断插件路由是否接收到插件调用请求；

若插件路由接收到插件调用请求，判断所述调用请求是否合法；

若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型；

调用插件入口方法以获取相应的插件执行结果；

将所述插件执行结果转换成特定参数类型。

作为优选的，所述处理器还用于执行如下步骤，

根据调用方的配置数据判断调用方是否有调用权限；

其中，若所述调用方有调用权限，则处理器用于执行所述加载插件文件并将所述插件文件转换为插件类型的步骤。

作为优选的，所述处理器还用于执行如下步骤，

记录符合预设条件的插件并生成调用方访问日志。

作为优选的，所述处理器执行所述判断所述调用请求是否合法包括执行如下步骤，

根据所述调用请求获取插件配置数据；

判断所述插件配置数据与第一预设数据是否相同。

作为优选的，所述处理器执行所述加载插件文件并将所述插件文件转换为插件类型包括执行如下步骤，

根据所述调用请求获取插件编号；

根据所述插件编号确定所述插件路由中的插件安装路径；

根据所述插件安装路径定位并加载相关的插件文件；

将所述插件文件转换为插件类型。

本发明的有益效果如下：

本发明的调用方法和装置能够在基于.NET框架的条件下实现插件的独立性，同时还能使得代码插件能够灵活的组合应用，降低耦合，提升插件的开发使用效率。

另外，本发明的调用方法和装置还允许抽离出大量的独立性的插件功能，降低功能模块间的耦合；并支持细粒度的模块级别、类级别，甚至方法级别的插件划分，从而使得插件的版本控制灵活度更高；还支持在不重启Web应用站点的前提下，做到新插件功能的“即插即用”以及旧插件功能的热更新。

总的来说该调用方法下的代码插件能够作为独立的模块、功能以及UI生成器从而实现灵活组合应用，以便Web应用中项目、模块、功能的快速演进与迭代优化，降低耦合，提升开发效率，扩大线上运维的手段与空间，减少维护性风险。

附图说明

图1为本发明一种后端代码插件的调用方法的较佳实施方式的流程示意图；

图2为本发明代码插件的结构示意图；

图3为本发明一种后端代码插件的调用方法中步骤S102的子步骤的流程示意图；

图4为本发明一种后端代码插件的调用方法中步骤S103的子步骤的流程示意图；

图5为本发明一种装置的结构示意图。

具体实施方式

下面将结合附图以及具体实施方式，对本发明做进一步描述：

请参见图1，本发明涉及一种后端代码插件的调用方法，其较佳实施方式包括如下步骤，

步骤S101，判断插件路由是否接收到插件调用请求。

其中，实现本步骤需要利用HTTP路由策略，即拦截并接收相关的插件调用请求。具体的，如图2所示，一个完整的插件应用包括有代码插件基类(Ucsmy.PlugIn.CodeBase)，该代码插件基类用于提供插件基类定义与实现规范，其结构与要点如下：

a.提供一个供外界调用的唯一入口方法，如CodeBase.CallResult；

b.CodeBase.CallResult采用“开放式”的参数策略，不假定参数的类型、传递的形式，而是按照具体使用环境、场景的不同，由代码插件自身决定，比如在ASP.NET环境下，可直接通过HttpRequest获取web请求的参数信息(Url-Get/Form-Post/Cookie/Session等等)，或者通过弱类型的CodeBase.RequestData(内容可以是xml、json、字典等)，供插件路由组装传递至具体插件，并由插件自行转换为需要的具体参数类型；

c)CodeBase.CallResult对外暴露唯一的返回值CodeBase.ServiceResult，基础参数如下Action-插件自述名称、RunsStatus-执行结果、PromptCode-执行提示编码、PromptMsg-执行提示信息、Remark-备注信息、DicData-自定义数据字典等。

步骤S102，若插件路由接收到插件调用请求，判断所述调用请求是否合法。

其中，一个插件应用还包括有插件路由(Ucsmy.PlugIn.Route)，插件路由负责执行调用特定的插件实现，可采用不同的实现形式(aspx页面、HttpHandler、HttpModule等均可，也可根据需要，定义不同的http路由策略)，定义不同的插件规则或约定。

插件路由主要提供以下功能：

a.作为外界调用某组特定代码插件功能的统一入口；

b.解析插件请求，定位并加载相关代码插件；

c.执行插件入口方法，并将执行结果返回。

当然，还可以根据需要在插件路由中增加相应的功能，比如进行合法性校验、调用方权限控制，对特定插件请求或者返回参数的解析、调用日志记录等。

例如，关于插件路由RouteA的路由规范实例，根据图2所示可知：

a.由RouteAHandler.aspx页面接管插件请求，并且仅受理POST请求，须通过配置HTTP路由策略，拦截并处理以下三种形式的Web访问(三层路径中，RouteA固定不变，而{path1}与{path2}均可代表“插件编号”，不过，{path2}一般作为扩展性需要而存在，大部分情况下，{path1}已经能够满足需求)：

[url-1,domain.com/RouteA/]

[url-2,domain.com/RouteA/{path1}/]

[url-3,domain.com/RouteA/{path1}/{path2}/]

b.可识别的插件安置目录，约定为Web站点下的/RouteA/文件夹；

c.可识别的插件形式，约定为用户自定义控件，并且命名规范为“插件编号.ascx”，采用“动态加载特定路径的ascx控件，并且转换其类型为插件基类，以便调用基类中所定义的插件入口方法”，来完成具体的插件加载；

d.调用返回值形式，此处采用json形式。

另外，具体的，判断调用请求是否合法可以是进行常规的“判断插件编号是否合法”、“判断插件相关文件是否存在”、“插件请求参数是否规范”等校验，或根据实际需要，扩展增加其他必要校验手段。若校验通不过，即所述调用请求是不合法的，那么此时将返回调用失败的信息。

作为优选的，如图3所示，所述步骤S102具体还可以包括以下子步骤，

步骤S201，根据所述调用请求获取插件配置数据。

步骤S202，判断所述插件配置数据与第一预设数据是否相同。

若所述插件配置数据与所述第一预设数据是相同的，则表明通过了校验，即所述调用请求是合法的。反之，则表明调用请求是不合法的，将返回调用失败的信息。

步骤S103，若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型。

其中，若加载或者转换类型失败，将抛出异常，并放回调用方特定的异常信息。

具体的，一个插件应用还包括有依据代码插件基类与特定路由规范而实现的完成特定功能的插件。例如，如下基于RouteA规范的插件实现示例--GetHotProducts(获取热销商品数据)包括：

a.新建一个用户自定义控件如GetHotProducts.ascx，删除其默认的CodeBehind文件GetHotProducts.ascx.cs(相当于清除了原始基类)，且声明其基类为CodeBase；

b.实现基类方法CodeBase.CallResult，在此方法中加载热销商品数据HotProducts，再通过调用CodeBase.ServiceResult.SetData(“HotProducts”,HotProducts)将此数据装载到DicData字典中(RouteA将能够完整接收到此数据，并最终以JSON形式完整返回给调用方)，最后返回调用成功信息；；

c.安置此代码插件文件到RouteA约定好的目录下(如上述提到，此处约定在Web站点下的/RouteA/文件夹)，此时插件已可正常被调用(如通过HttpWebRequest构造路径为domain.com/RouteA/GetHotProducts的Post请求。

作为优选的，如图4所示，所述步骤S103包括以下子步骤，

步骤S301，根据所述调用请求获取插件编号。

步骤S302，根据所述插件编号确定所述插件路由中的插件安装路径。

步骤S303，根据所述插件安装路径定位并加载相关的插件文件。

步骤S304，将所述插件文件转换为插件类型。

具体的，根据调用请求的插件编号，结合插件路由的插件安装路径，可以定位并加载相关的插件文件，并将该插件文件转换为插件基础类型CodeBase。

步骤S104，调用插件入口方法以获取相应的插件执行结果。

其中，本步骤将执行已加载成功的插件的插件入口方法(CodeBase.CallResult)，以获取插件执行结果ServiceResult。当然，插件执行前，若有特殊需求，可按实际情况增加额外的步骤，如“组装特定的参数到RequestData中”。

步骤S105，将所述插件执行结果转换成特定参数类型。

其中，可以根据获取的插件执行结果ServiceResult，转换成特定参数类型(JSON、XML、自定义格式文本等等)，并返回调用方，结束流程。

另外，作为进一步优选的，所述步骤S103之前还可以包括，

步骤S103′，根据调用方的配置数据判断调用方是否有调用权限。其中，若所述调用方有调用权限，则执行所述步骤103。调用方的配置数据可以根据实际需要自行定义。判断调用方是否有调用权限能够有效地提高插件使用的安全性能。

作为进一步优选的，所述步骤S105之后还可以包括，

步骤S106，记录符合预设条件的插件并生成调用方访问日志。

其中，在返回执行结果前，若有特殊需求，可按实际情况增加步骤S106，从而使得该调用方法更为方便实用，提高用于的使用体验度。同时，在返回执行结果前，还可以过滤或检查返回值中的敏感信息，从而进一步完善该调用方法。

总的来说，本发明的调用方法能够在基于.NET框架的条件下实现插件的独立性，同时还能使得代码插件能够灵活的组合应用，降低耦合，提升插件的开发使用效率。同时，该调用方法下的代码插件能够作为独立的模块、功能以及UI生成器从而实现灵活组合应用，以便Web应用中项目、模块、功能的快速演进与迭代优化，降低耦合，提升开发效率，扩大线上运维的手段与空间，减少维护性风险。

另外，如图5所示，本发明还提供一种装置，所述装置100包括，

存储器101，用于存储程序指令；

处理器102，用于运行所述程序指令，以执行以下步骤，

步骤S101，判断插件路由是否接收到插件调用请求。

其中，实现本步骤需要利用HTTP路由策略，即拦截并接收相关的插件调用请求。具体的，如图2所示，一个完整的插件应用包括有代码插件基类(Ucsmy.PlugIn.CodeBase)，该代码插件基类用于提供插件基类定义与实现规范，其结构与要点如下：

a.提供一个供外界调用的唯一入口方法，如CodeBase.CallResult；

b.CodeBase.CallResult采用“开放式”的参数策略，不假定参数的类型、传递的形式，而是按照具体使用环境、场景的不同，由代码插件自身决定，比如在ASP.NET环境下，可直接通过HttpRequest获取web请求的参数信息(Url-Get/Form-Post/Cookie/Session等等)，或者通过弱类型的CodeBase.RequestData(内容可以是xml、json、字典等)，供插件路由组装传递至具体插件，并由插件自行转换为需要的具体参数类型；

c)CodeBase.CallResult对外暴露唯一的返回值CodeBase.ServiceResult，基础参数如下Action-插件自述名称、RunsStatus-执行结果、PromptCode-执行提示编码、PromptMsg-执行提示信息、Remark-备注信息、DicData-自定义数据字典等。

步骤S102，若插件路由接收到插件调用请求，判断所述调用请求是否合法。

其中，一个插件应用还包括有插件路由(Ucsmy.PlugIn.Route)，插件路由负责执行调用特定的插件实现，可采用不同的实现形式(aspx页面、HttpHandler、HttpModule等均可，也可根据需要，定义不同的http路由策略)，定义不同的插件规则或约定。

插件路由主要提供以下功能：

a.作为外界调用某组特定代码插件功能的统一入口；

b.解析插件请求，定位并加载相关代码插件；

c.执行插件入口方法，并将执行结果返回。

当然，还可以根据需要在插件路由中增加相应的功能，比如进行合法性校验、调用方权限控制，对特定插件请求或者返回参数的解析、调用日志记录等。

例如，关于插件路由RouteA的路由规范实例，根据图2所示可知：

a.由RouteAHandler.aspx页面接管插件请求，并且仅受理POST请求，须通过配置HTTP路由策略，拦截并处理以下三种形式的Web访问(三层路径中，RouteA固定不变，而{path1}与{path2}均可代表“插件编号”，不过，{path2}一般作为扩展性需要而存在，大部分情况下，{path1}已经能够满足需求)：

[url-1,domain.com/RouteA/]

[url-2,domain.com/RouteA/{path1}/]

[url-3,domain.com/RouteA/{path1}/{path2}/]

b.可识别的插件安置目录，约定为Web站点下的/RouteA/文件夹；

c.可识别的插件形式，约定为用户自定义控件，并且命名规范为“插件编号.ascx”，采用“动态加载特定路径的ascx控件，并且转换其类型为插件基类，以便调用基类中所定义的插件入口方法”，来完成具体的插件加载；

d.调用返回值形式，此处采用json形式。

另外，具体的，判断调用请求是否合法可以是进行常规的“判断插件编号是否合法”、“判断插件相关文件是否存在”、“插件请求参数是否规范”等校验，或根据实际需要，扩展增加其他必要校验手段。若校验通不过，即所述调用请求是不合法的，那么此时将返回调用失败的信息。

作为优选的，如图3所示，所述处理器102用于执行所述步骤S102还可以包括执行以下子步骤，

步骤S201，根据所述调用请求获取插件配置数据。

步骤S202，判断所述插件配置数据与第一预设数据是否相同。

若所述插件配置数据与所述第一预设数据是相同的，则表明通过了校验，即所述调用请求是合法的。反之，则表明调用请求是不合法的，将返回调用失败的信息。

步骤S103，若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型。

其中，若加载或者转换类型失败，将抛出异常，并放回调用方特定的异常信息。

具体的，一个插件应用还包括有依据代码插件基类与特定路由规范而实现的完成特定功能的插件。例如，如下基于RouteA规范的插件实现示例--GetHotProducts(获取热销商品数据)包括：

a.新建一个用户自定义控件如GetHotProducts.ascx，删除其默认的CodeBehind文件GetHotProducts.ascx.cs(相当于清除了原始基类)，且声明其基类为CodeBase；

b.实现基类方法CodeBase.CallResult，在此方法中加载热销商品数据HotProducts，再通过调用CodeBase.ServiceResult.SetData(“HotProducts”,HotProducts)将此数据装载到DicData字典中(RouteA将能够完整接收到此数据，并最终以JSON形式完整返回给调用方)，最后返回调用成功信息；；

c.安置此代码插件文件到RouteA约定好的目录下(如上述提到，此处约定在Web站点下的/RouteA/文件夹)，此时插件已可正常被调用(如通过HttpWebRequest构造路径为domain.com/RouteA/GetHotProducts的Post请求。

作为优选的，如图4所示，所述处理器102执行所述步骤S103还可以包括执行以下子步骤，

步骤S301，根据所述调用请求获取插件编号。

步骤S302，根据所述插件编号确定所述插件路由中的插件安装路径。

步骤S303，根据所述插件安装路径定位并加载相关的插件文件。

步骤S304，将所述插件文件转换为插件类型。

具体的，根据调用请求的插件编号，结合插件路由的插件安装路径，可以定位并加载相关的插件文件，并将该插件文件转换为插件基础类型CodeBase。

步骤S104，调用插件入口方法以获取相应的插件执行结果。

其中，本步骤将执行已加载成功的插件的插件入口方法(CodeBase.CallResult)，以获取插件执行结果ServiceResult。当然，插件执行前，若有特殊需求，可按实际情况增加额外的步骤，如“组装特定的参数到RequestData中”。

步骤S105，将所述插件执行结果转换成特定参数类型。

其中，可以根据获取的插件执行结果ServiceResult，转换成特定参数类型(JSON、XML、自定义格式文本等等)，并返回调用方，结束流程。

另外，作为进一步优选的，处理器101执行所述步骤S103之前还可以执行以下步骤，

步骤S103′，根据调用方的配置数据判断调用方是否有调用权限。其中，若所述调用方有调用权限，则执行所述步骤103。调用方的配置数据可以根据实际需要自行定义。判断调用方是否有调用权限能够有效地提高插件使用的安全性能。

作为进一步优选的，处理器执行所述步骤S105之后还可以执行以下步骤，

步骤S106，记录符合预设条件的插件并生成调用方访问日志。

其中，在返回执行结果前，若有特殊需求，可按实际情况增加步骤S106，从而使得该调用方法更为方便实用，提高用于的使用体验度。同时，在返回执行结果前，还可以过滤或检查返回值中的敏感信息，从而进一步完善该调用方法。

对于本领域的技术人员来说，可根据以上描述的技术方案以及构思，做出其它各种相应的改变以及变形，而所有的这些改变以及变形都应该属于本发明权利要求的保护范围之内。

Claims (10)

1.一种后端代码插件的调用方法，其特征在于，包括如下步骤，

判断插件路由是否接收到插件调用请求；

若插件路由接收到插件调用请求，判断所述调用请求是否合法；

若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型；

调用插件入口方法以获取相应的插件执行结果；

将所述插件执行结果转换成特定参数类型。

2.如权利要求1所述的调用方法，其特征在于，所述加载插件文件并将所述插件文件转换为插件类型的步骤之前还包括，

根据调用方的配置数据判断调用方是否有调用权限；

其中，若所述调用方有调用权限，则执行所述加载插件文件并将所述插件文件转换为插件类型的步骤。

3.如权利要求1所述的调用方法，其特征在于，所述将所述插件执行结果转换成特定参数类型的步骤之后还包括，

记录符合预设条件的插件并生成调用方访问日志。

4.如权利要求1所述的调用方法，其特征在于，所述判断所述调用请求是否合法包括，

根据所述调用请求获取插件配置数据；

判断所述插件配置数据与第一预设数据是否相同。

5.如权利要求1所述的调用方法，其特征在于，所述加载插件文件并将所述插件文件转换为插件类型包括，

根据所述调用请求获取插件编号；

根据所述插件编号确定所述插件路由中的插件安装路径；

根据所述插件安装路径定位并加载相关的插件文件；

将所述插件文件转换为插件类型。

6.一种装置，其特征在于，包括，

存储器，用于存储程序指令；

处理器，用于运行所述程序指令，以执行以下步骤，

判断插件路由是否接收到插件调用请求；

若插件路由接收到插件调用请求，判断所述调用请求是否合法；

若所述调用请求合法，加载插件文件并将所述插件文件转换为插件类型；

调用插件入口方法以获取相应的插件执行结果；

将所述插件执行结果转换成特定参数类型。

7.如权利要求6的所述的装置，其特征在于，所述处理器还用于执行如下步骤，

根据调用方的配置数据判断调用方是否有调用权限；

其中，若所述调用方有调用权限，则处理器用于执行所述加载插件文件并将所述插件文件转换为插件类型的步骤。

8.如权利要求6所述的装置，其特征在于，所述处理器还用于执行如下步骤，

记录符合预设条件的插件并生成调用方访问日志。

9.如权利要求6所述的装置，其特征在于，所述处理器执行所述判断所述调用请求是否合法包括执行如下步骤，

根据所述调用请求获取插件配置数据；

判断所述插件配置数据与第一预设数据是否相同。

10.如权利要求6所述的装置，其特征在于，所述处理器执行所述加载插件文件并将所述插件文件转换为插件类型包括执行如下步骤，

根据所述调用请求获取插件编号；

根据所述插件编号确定所述插件路由中的插件安装路径；

根据所述插件安装路径定位并加载相关的插件文件；

将所述插件文件转换为插件类型。