CN111580814B - Guitar中间层渲染系统 - Google Patents

Abstract

本申请涉及数据处理相关技术领域，尤其涉及一种Guitar中间层渲染系统。Guitar中间层渲染系统，包括：业务服务器、中间层和客户端；业务服务器向中间层提供待处理的业务数据；中间层对业务数据进行处理，生成并向客户端发送匹配客户端的视图数据；客户端接收并显示视图数据对应的视图。基于此，由于视图数据是在中间层进行生成的，所以当需要当业务需要调整的显示方式时，产品人员可以在中间层自由的编辑数据的展示，即：只修要修改中间层的部分程序，便可以使得客户端的显示信息按照预设的要求进行显示。当需要更新视图中内容的时候不再需要客户端重新发版。只要对中间层进行简单的映射编辑即可。

Description

Guitar中间层渲染系统

技术领域

本申请涉及数据处理相关技术领域，尤其涉及一种Guitar中间层渲染系统。

背景技术

现行状态下，开发模式由服务端提供业务数据，客户端根据业务数据展现对应的样式，当业务需要调整的显示方式需要频繁通过版本发布的形式来进行更新。

实际应用中，频繁的更新客户端的版本会给客户带来较差的用户体验，同时提高了客户端应用的发布成本。

发明内容

为至少在一定程度上克服相关技术中存在的问题，本申请提供一种Guitar中间层渲染系统。

本申请提供一种Guitar中间层渲染系统，包括：业务服务器、中间层和客户端；

所述业务服务器向所述中间层提供待处理的业务数据；

所述中间层对所述业务数据进行处理，生成并向所述客户端发送匹配所述客户端的视图数据；

所述客户端接收并显示所述视图数据对应的视图。

可选的，所述视图数据包括：多个视图组件信息；

所述中间层设置组件库；所述组件库内设置有多个规则组件；

所述规则组件为所述业务数据与对应的视图组件之间的映射关系，用于将所述业务数据转化为视图组件信息。

可选的，所述中间层通过改变所述组件库内的规则组件，改变所述客户端上显示的视图。

可选的，所述客户端还用于向中间层发送业务数据请求；其中，所述业务数据请求用于请求目标业务数据；

所述中间层基于所述业务数据请求，向业务服务器请求目标业务数据；

所述业务服务器在接收到所述中间层的请求后，向所述中间层发送目标业务数据。

可选的，所述中间层和所述业务服务器之间的数据以OpenAPI Specification为标准定义。

可选的，所述视图组件信息由JSON Schema规范进行定义。

可选的，所述视图组件信息由配套工具JSON Schema Validate进行校验。

可选的，所述中间层搭建方法；包括：

分别搭建所述中间层的规则组件；

判断所述规则组件是否合格，若不合格则重新进行搭建；

整合合格的规则组件进构成一个中间层。

可选的，所述中间层迭代方法包括：

确定需要进行迭代的目标组件；

搭建目标组件；

基于目标组件对中间层进行迭代。

可选的，所述中间层迭代方法包括：

判断目标组件是否合格；

若不合格则重新搭建所述目标组件。

本申请的实施例提供的技术方案可以包括以下有益效果：

本专利的中间层和业务服务器之间进行数据的交互，所述中间层对所述业务数据进行处理，生成并向所述客户端发送匹配所述客户端的视图数据；所述客户端接收并显示所述视图数据对应的视图。基于此，由于视图数据是在中间层进行生成的，所以当需要当业务需要调整的显示方式时，产品人员可以在中间层自由的编辑数据的展示，即：只修要修改中间层的部分程序，便可以使得客户端的显示信息按照预设的要求进行显示。即：当需要更新视图中内容的时候不再需要客户端重新发版。只要对中间层进行简单的映射编辑即可。如此减少了客户端新版本的发布，避免频繁的更新客户端的版本给客户带来较差的用户体验，降低提高了客户端应用的发布成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种Guitar中间层渲染系统的结构示意图；

图2为本申请实施例提供的一种Guitar中间层渲染系统中所述中间层搭建方法的流程示意图；

图3为本申请实施例提供的一种Guitar中间层渲染系统中所述中间层迭代方法的流程示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

现行状态下，开发模式由服务端提供业务数据，客户端3根据业务数据展现对应的样式，当业务需要调整的方式需要频繁通过版本发布的形式来进行更新。本发明解决的问题就是在客户端3和业务数据服务端中间设立一个中间层2，来将业务数据组织成视图数据，然后交由客户端3直接渲染视图数据。这样可以大幅增加产品变更的灵活性。具体的方案如下所述：

图1为本申请实施例提供的一种Guitar中间层2渲染系统的结构示意图。如图1所示，Guitar中间层2渲染系统包括：业务服务器1、中间层2和客户端3；

所述业务服务器1向所述中间层2提供待处理的业务数据；

所述中间层2对所述业务数据进行处理，生成并向所述客户端3发送匹配所述客户端3的视图数据；

所述客户端3接收并显示所述视图数据对应的视图。

本专利的中间层2和业务服务器1之间进行数据的交互，所述中间层2对所述业务数据进行处理，生成并向所述客户端3发送匹配所述客户端3的视图数据；所述客户端3接收并显示所述视图数据对应的视图。基于此，由于视图数据是在中间层2进行生成的，所以当需要当业务需要调整的显示方式时，产品人员可以在中间层2自由的编辑数据的展示，即：只修要修改中间层2的部分程序，便可以使得客户端3的显示信息按照预设的要求进行显示。即：当需要更新视图中内容的时候不再需要客户端3重新发版。只要对中间层2进行简单的映射编辑即可。如此减少了客户端3新版本的发布，避免频繁的更新客户端3的版本给客户带来较差的用户体验，降低提高了客户端3应用的发布成本。

进一步的，所述视图数据包括：多个视图组件信息；

所述中间层2设置组件库；所述组件库内设置有多个规则组件；

所述规则组件为所述业务数据与对应的视图组件之间的映射关系，用于将所述业务数据转化为视图组件信息。

所述中间层2通过改变所述组件库内的规则组件，改变所述客户端3上显示的视图。

具体的，例如客户端3上一个显示页面一般包括：菜单栏、内容框；内容框内具有各种信息。对于一个与业务数据有关的app，其内容框内可能展示的是各种数据，且可能通过多个折线图展示某些数据。这些展示的信息中，每一个折线图，或者每一个菜单栏中的按键便是一个视图组件。客户端3可以基于中间层2向所述客户端3发送的视图组件数据生成视图组件。客户端3可以接收中间层2发送的视图组件数据，之后基于视图组件数据，确定视图组件，基于视图组件数据和预设规则组合各个试图组件，从而构成一整个视图。

所述中间层2设置组件库；所述组件库内设置有多个规则组件；具体的，每个规则组件可以对应一个视图组件信息，用于将对应的业务数据转化为试图组件信息。当然规则组件中生成的数据组件数据中部分组件用于指导客户端3组合视图组件。

当需要需要调整画面展示的信息时，例如将需要之前的折线图，调整为柱状图。那么只需要调整中间层2的内的信息，调整中间层2的组件规则，进而调整生成的视图组件信息，组件使得视图组件信息便可以调整客户端3上显示的信息。例如，之前客户端3显示A组数据的视图组件，现在想要显示B组数据，那么只需要调整中间层2内的规则组件内的逻辑映射关系，使得视图组件数据中映射关系改变，对应B组数据，那么客户端3接收数据组件信息后，组合并显示的图像中，显示的便是B组数据对应的信息。如此设置，没无需改变客户端3的内容和版本只需要调节中间层2的内容便可以完成app的调整。

进一步的，实际应用中，所述客户端3还用于向中间层2发送业务数据请求；其中，所述业务数据请求用于请求目标业务数据；

所述中间层2基于所述业务数据请求，向业务服务器1请求目标业务数据；

所述业务服务器1在接收到所述中间层2的请求后，向所述中间层2发送目标业务数据。

实际应用中，在用户与客户端3进行交互的过程中，客户端3不仅仅需要进行数据等信息的展示，还需要向业务服务器1请求数据，本申请提供的方案中，客户端3将请求发送给中间层2，由中间层2进行数据的请求，如此设置，当业务服务器1的规则改变时，只需要改变中间层2的规则组件便可以进行数据的寻求，进一步的减少客户端3版本的改变。

需要说明的是，本申请只是减少客户端3更新的次数，而不是彻底不对客户端3进行更新。当进行一些实际客户端3的逻辑的变更时，需要对客户端3进行更新。本申请提供的方案只是将大部分的更新转化为对于中间层2的更新，从而减少对于客户端3的更新。

具体的，本申请提供的方案中，所述中间层2和所述业务服务器1之间的数据以OpenAPI Specification为标准定义。所述视图组件信息由JSON Schema规范进行定义。所述视图组件信息由配套工具JSON Schema Validate进行校验。

本专利的中间层2和业务服务器1之间的数据以OpenAPI Specification为标准定义，使得中间层2与业务数据中的每一个细节都有非常明确的定义。由于定义明确，所以，中间层2根据数据文档即可获取到所有的数据资源、以及获取这些资源所需要的条件(客户端3请求内容)。当客户端3需要展示某个页面的时候，向中间层2获取视图数据。每个视图组件由JSON Schema规范进行定义，以及配套工具JSON Schema Validate进行校验。中间层2根据产品人员编辑好的页面的组件内容、每个组件内容所对应的业务数据来请求业务数据服务器，请求到之后，根据产品人员编辑的数据关系组织好视图数据，并下发给客户端3。基于以上，产品人员可以在中间层2自由的编辑数据的展示，当需要更新视图中内容的时候不再需要客户端3重新发版。只要进行简单的映射编辑即可。

图2为本申请实施例提供的一种Guitar中间层2渲染系统中所述中间层2搭建方法的流程示意图。参照图2，中间层2搭建方法包括以下步骤：

在步骤S201中，分别搭建所述中间层2的规则组件；

具体的，参照上文中的说明，中间层2中包括多种规则组件，本申请实施例提供的方案中，每一个规则组件由一个员工进行搭建。当然实际应用中可以一个员工搭建多个规则组件，或者多个员工搭建一个组件。本实施例的重点为：各个规则组件是相对独立的，如此可以较为方便的进行搭建工作中各个搭建工作部分的划分，明确各个员工负责的部分，让开发工作颗粒更加明显。

在步骤S202中，判断所述规则组件是否合格，若不合格则重新进行搭建；

在步骤S203中，整合合格的规则组件进构成一个中间层2。

由于本实施例提供的方案中，工作颗粒较为明显，即各个规则组件的划分较为明确。所以当规则组件合格后可以整合各个规则组件构成一个中间层2。当其中某一个或某一些组件不合格时，也不会影响其他组件的开发工作。不会使得整个工作流程混乱。同时由于开发工作颗粒明显，便于对开发过程中不合格的地方进行追责。

图3为本申请实施例提供的一种Guitar中间层2渲染系统中所述中间层2迭代方法的流程示意图。参照图3，本实施例提供的中间层2迭代方法包括以下步骤：

在步骤S301中，确定需要进行迭代的目标组件；

本申请提供的方案，核心便是通过中间层2的更新代替客户端3的更新，从而减少客户端3的更新次数。即：当需要对客户端3进行调整时，基于需要调整的内容，确定中间层2中需要进行迭代的规则组件(即：目标组件)。

在步骤S302中，搭建目标组件；

在步骤S305中，基于目标组件对中间层2进行迭代。

需要说明的是，此处搭建目标组件主要包括两种搭建方式。一种是基于客户端3的需求进行新的规则组件的搭建，另一种是基于客户端3的需求对原有的客户端3进行调整。之后将新搭建的规则组件添加进中间层2的组件库，或者对组件库中的某一个进行替换，从而完成对于中间层2的迭代。

进一步的，中间层2迭代方法还包括如下步骤：

在步骤S302中，判断目标组件是否合格；

在步骤S303中，若不合格则重新搭建所述目标组件。

如此设置，可以确保将目标组件添加或者替换进入目标组件之后，可以正常工作。

通过上述迭代方式，将原本对于客户端3的版本更新改变为对于中间层2的迭代，不仅仅降低了客户端3的更新速度，同时，由于本申请提供的方案中，可以颗粒化分工(即：各个规则组件相互独立)，使得项目开发的工作内容、进度、风险等更容易被量化评估。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (8)

1.一种Guitar中间层渲染系统，其特征在于，包括：业务服务器、中间层和客户端；

所述业务服务器向所述中间层提供待处理的业务数据；

所述中间层对所述业务数据进行处理，生成并向所述客户端发送匹配所述客户端的视图数据；

所述客户端接收并显示所述视图数据对应的视图；

所述视图数据包括：多个视图组件信息；

所述中间层设置组件库；所述组件库内设置有多个规则组件；

所述规则组件为所述业务数据与对应的视图组件之间的映射关系，用于将所述业务数据转化为视图组件信息所述中间层通过改变所述组件库内的规则组件，改变所述客户端上显示的视图。

2.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述客户端还用于向中间层发送业务数据请求；其中，所述业务数据请求用于请求目标业务数据；

所述中间层基于所述业务数据请求，向业务服务器请求目标业务数据；

所述业务服务器在接收到所述中间层的请求后，向所述中间层发送目标业务数据。

3.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述中间层和所述业务服务器之间的数据以OpenAPI Specification为标准定义。

4.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述视图组件信息由JSON Schema规范进行定义。

5.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述视图组件信息由配套工具JSON Schema Validate进行校验。

6.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述中间层搭建方法；包括：

分别搭建所述中间层的规则组件；

判断所述规则组件是否合格，若不合格则重新进行搭建；

整合合格的规则组件进构成一个中间层。

7.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述中间层迭代方法包括：

确定需要进行迭代的目标组件；

搭建目标组件；

基于目标组件对中间层进行迭代。

8.根据权利要求1所述的Guitar中间层渲染系统，其特征在于，所述中间层迭代方法包括：

判断目标组件是否合格；

若不合格则重新搭建所述目标组件。