CN116185397A

CN116185397A - 一种基于声明式组件的低代码引擎

Info

Publication number: CN116185397A
Application number: CN202211539569.6A
Authority: CN
Inventors: 石屹; 石鹏
Original assignee: Shanghai Qilan Technology Co ltd
Current assignee: Shanghai Qilan Technology Co ltd
Priority date: 2022-12-02
Filing date: 2022-12-02
Publication date: 2023-05-30

Abstract

本发明公开了一种基于声明式组件的低代码引擎，涉及代码开发领域。本发明的引擎包括元数据模块、数据动态加载模块、逻辑执行模块和页面渲染模块，来满足用户不需要重新部署就可以调整界面，逻辑以及模型的来满足自定义需求的方法；使用元数据结合数据库online DDL实现在线数据变更。页面的调整使用页面渲染框架，结合页面协议来实时变更。逻辑的变更使用数据动态加载模块和逻辑执行模块来实现实时变更。本发明的优势是用戶/系统定义的页面是动态的，可以根据实际的页面定义动态生成。并且通过各个模块的配合，用户可以在短时间调整或新建不同的页面，展示不同的数据，而不需要修改代码重新部署。

Description

一种基于声明式组件的低代码引擎

技术领域

本发明属于代码开发领域，特别是涉及一种基于声明式组件的低代码引擎。

背景技术

在低代码领域，目前的应用解决重复设计和应对不同需求的方法有：定制化开发，在客户已有的系统基础上进行二次开发；如论文“ERP系统实施前应建立的基本理念”的中所提到的，比如公司已经使用了SAP或者其它ERP系统，但是业务无法进行完全的标准化，或者现有系统无法支持，那么客户就需要找专业的开发团队来对系统进行二次开发。

现有技术中也有很多关于二次开发的一些研究，如CN111241089A，ERP系统二次开发方法、系统、装置及可读存储介质，其具体是通过在客户端上架构的ERP系统上提供有字段设计器窗体、表设计器窗体、数据窗体设计器窗体、方案设计器窗体以及窗体设计器窗体，其中，字段设计器窗体上提供有预设的标准字段名，方案设计器窗体内置有常用控件，控件包括逻辑实现模块,界面设计模块以及功能业务逻辑控制模块。其具体的二次开发功能通过字段设计器、表设计器、数据窗口设计器、方案设计器、窗体设计器，五个维度依次递进的自主设计，可以实现页面方案和窗体控件的自主设计降低二次开发门槛，任何人都可以以基于系统平台进行二次开发；同时允许通过SQL自主写入代码，生成新的控件或者程序。

二次开发本身耗时耗力且不易维护；使用元数据抽象，结合配置文件来实现通过配置更改软件逻辑的需求，比如正常的业务逻辑实现通过判断配置文件中的条件来具体运行对应的逻辑。上述所提到的现有技术中的二次开发在具体实践过程中都具有以下缺陷：一是客户的定制化代码十分难于维护，并且随着主功能的审计，分支会越来越多，难以处理；二是标准化的流程很难估计客户的方方面面，一般企业内部系统还是需要贴合企业的运转模式来设计，才能够让企业的信息化更贴合实际情况；三是现有的软件进行定制化开发需要重新修改代码，更改数据库，然后部署新的版本；这种方法的实施流程很长，并且中间无法适应随时变更的需求。

发明内容

本发明提供了一种基于声明式组件的低代码引擎，解决了以上问题。

为解决上述技术问题，本发明是通过以下技术方案实现的：

本发明的一种基于声明式组件的低代码引擎，该引擎包括元数据模块、数据动态加载模块、逻辑执行模块和页面渲染模块，满足用户不需要重新部署就可以调整界面、逻辑以及模型来满足自定义需求；

使用元数据结合数据库online DDL实现在线数据变更；页面的调整使用页面渲染框架，结合页面协议来实时变更；使用数据动态加载模块和逻辑执行模块来实现逻辑的实时变更；

对于一个页面操作的数据流程如下：

S1、用户请求一个页面；

S2、请求页面的指令通过前端渲染模块传递到数据动态加载模块；

S3、动态加载模块根据用户请求的页面从元数据模块获取页面元数据，并按照页面交互协议拼接成对应的内容；

S4、动态加载模块返回具体的页面信息给前端渲染模块；

S5、前端渲染模块对页面数据进行处理，处理过程包括解析其依赖，加载其它依赖数据，最终渲染成浏览器可以使用的网页；

对于用户修改系统的数据流程如下：

P1、用户发送一个修改元数据的指令；

P2、修改指令通过api传递到元数据服务，元数据服务根据对应的指令进行onlineDDL的处理；

P3、元数据服务将对应的更新推送到数据库，对应数据库表结构的增加、修改和删除；

P4、当模型字段更新完成后，用户将新增的字段添加到指定的订单页面，需要发送一个页面管理指令，在需要的位置增加一个字段；

P5、元数据服务受到对应的更改需求，找到对应的页面元数据，并对其进行更新；

P6、新的页面元数据存储到数据库中；

P7、用户的更新全部完成。

进一步地，所述数据动态加载模块通过定义数据模型的视图元数据来控制模型的展示逻辑，模型视图的数据定义包括视图展示的字段以及视图对应的模型筛选；

所述视图展示的字段是指数据视图存储的字段会保存在元数据服务中作为视图的一个部分；所述视图对应的模型筛选是指视图的筛选条件通过DSL把模型序列化存储，DSL的模型定义有很多方案，大多数支持查询的筛选的定义。

进一步地，所述元数据模块存储有包括实体、页面、视图及操作的元数据信息；

所述实体的元数据是业务领域模型，与数据库的表一一对应，一个实体就是一个表；业务的实体可添加业务属性；包括在实体上增加属性来标识实体是否有校验，是否和流程绑定；

所述页面的元数据是描述页面的组件并将组件编排的数据；

所述视图的元数据是实体元数据的关联数据，描述实体的过滤和查询条件，通过DSL模型进行定义和存储；

所述操作的元数据是领域模型对应的一个api调用，包括“下单”、“审核”等动作，实际对应一个api的调用；操作的元数据记录了调用对应的api定义。

进一步地，所述实体的元数据存储了实体模型，包括模型名称和字段，实体的模型和数据表对应的，实体的模型的变更会触发online DDL，并且改动都是在事务中保持一致性。

进一步地，所述页面的元数据通过Json的方式定义出的页面模型与页面渲染模块用到的页面协议模型是一致的，并通过使用Json定义页面中用到的组件Control以及每个页面如何编排的逻辑；并且，所述页面中可绑定页面指令，每个指令均绑定于具体的控件中。

进一步地，所述视图的元数据记录了视图相关的过滤字段及条件DSL，用于在数据加载模块动态的获取视图，并且根据视图的描述来实时的加载视图指定的内容；所述数据动态加载模块使用视图元数据定义的内容来加载对应的数据。

进一步地，所述操作的元数据记录了操作对应的描述Json，操作的元数据和页面指定相对应，操作元数据可以被指定的模块转换成对应的操作。

本发明相对于现有技术包括有以下有益效果：

(1)本技术方案的引擎包括元数据模块、数据动态加载模块，逻辑执行模块和页面渲染模块，来满足用户不需要重新部署就可以调整界面逻辑以及模型的来满足自定义需求的方法；

(2)本技术方案针对现有技术方案中改动中的数据库变更，可以使用元数据结合数据库online DDL实现在线数据变更。页面的调整使用页面渲染框架，结合页面协议来实时变更。逻辑的变更使用数据动态加载模块和逻辑执行模块来实现实时变更；

(3)本技术方案用户/系统定义的页面是动态的，可以根据实际的页面定义动态生成。并且通过各个模块的配合，用户可以在短时间调整或新建不同的页面，展示不同的数据，而不需要修改代码重新部署。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本低代码引擎的系统的模块之间的关系图；

图2为实施例中基本用户网页展示在页面渲染模块的请求流程图；

图3为用户通过一系列的api操作不需要重新部署就获得新的页面原理图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1-3所示，本发明的一种基于声明式组件的低代码引擎，该引擎包括元数据模块、数据动态加载模块、逻辑执行模块和页面渲染模块，满足用户不需要重新部署就可以调整界面、逻辑以及模型来满足自定义需求；

一般现有的软件进行定制化开发需要重新修改代码，更改数据库库，然后部署新的版本。这种方法的实施流程很长，而且中间无法适应随时变更的需求。

本技术方案提供一系列方法来实现用户业务的实时调整，针对这类改动中的数据库变更，可以使用元数据结合数据库online DDL实现在线数据变更；页面的调整使用页面渲染框架，结合页面协议来实时变更；使用数据动态加载模块和逻辑执行模块来实现逻辑的实时变更；对应的本低代码引擎的系统的模块之间的关系图如图1所示；

其中：

页面是用户最终看到的网页，由浏览器自动渲染；

页面渲染模块是前端组件，用于将数据展示协议中的数据进行加工处理，并渲染成最终浏览器支持的页面；

页面展示协议是最后端对于页面的组件以及交互的约定，后端的模块会按照此约定构造对应的数据；

数据动态加载模块是基于元数据定义的模型进行数据加载的模块，加载的模式包括字段过滤和数据筛选；

逻辑执行模块是执行特定的业务逻辑，业务逻辑会读取元数据和数据库里面具体的数据然后进行执行；

元数据模块是对用户的业务数据模型进行存储，它和数据库的存储会对应起来，数据库实际的表结构会由元数据模块生成；

数据库使用关系数据库postgresql或者mysql，其它的关系型数据库也可以，没有做限制；

对于一个页面操作的数据流程如下：

S1、用户请求一个页面；

a、获取页面元数据的详细内容可以参考“页面展示协议”部分，页面的元数据包括页面的控件和页面的排布，举例来说，页面中如果包含了一个列表控件和详情信息，并且是竖向排布的，那么此信息就可以通过Json方式定义出来；

b、页面交互协议是指页面的操作的行为，一般会对应页面的按钮或者超链接，具体的行为是野蛮的跳转、页面的弹窗，发送一个同步请求，发送一个异步请求；

c、这里动态加载模块的进行的协议拼接需要做两部分的内容，一个是内容的合法性检查，根据请求的要求返回对应版本的页面，另一个是页面的标准化，包括页面的权限过滤；

S4、动态加载模块返回具体的页面信息给前端渲染模块；

a、页面的信息就是上述说的经过标准化的页面Json；

b、前端渲染模块参考“页面渲染模块”内容，其主要作用是根据页面定义的组件，渲染成对应的的html页面；

a、浏览器可使用的页面一般是html+js组合而成，页面协议中定义的前端组件可以渲染成对应的内容，其中，html主要是展示和编排，js部分是空间的交互部分；

对于用户修改系统的数据流程如下(是以使用用户需要添加一个订单字段为例)：

P1、用户发送一个修改元数据的指令；

a、元数据修改的指令一般为更新元数据的API，比如如下增加模型属性的API；

b、元数据服务负责接收修改的指令，修改对应的数据模型并推送到数据库，比如如上的一条修改指令，元数据服务会给商品模型添加一个“price”字段。并且把此修改转换成对应的数据库SQL；

alter table‘product’add column‘price’decimal；

c、元数据完成这一系列操作之后会返回给用户更新之后的模型和结构；

a、元数据进行更新推送的数据库这里实用关系型数据库postgresql；

b、Postgresql，在进行数据库更新的时候回进行字段的检查，如果字段不存在就增加新的字段，如果字段类型发生变化，则更新对应的数据库列，如果字段属性更新则直接更新；

c、如果整个流程的任何一个步骤有问题，则整个更新的过程会中断；

a、页面管理指令对应一个页面修改的API，此API会指定增加的字段是模型中的哪个字段，以及需要把此字段添加到具体页面的具体位置；

b、上述的页面修改的API表示增加一个页面控件在“page.paroduct.detail.grid”空间中的“page.paroduct.detail.grid.description”控件之后

P6、新的页面元数据存储到数据库中；

P7、用户的更新全部完成。

详细模块方案：

其中，页面渲染模块有两个功能：一是根据页面交互协议把页面元数据转换为具体的网页；二是接受用户的请求指令进行对应的操作转换，这里的操作转换有两类，一类是基本的数据读取和操作，另一类是元数据相关的管理操作；如图2所示，是一个基本用户网页展示在页面渲染模块的请求流程图；

页面展示协议：

页面展示协议是连接前后端和页面交互的一套描述，页面渲染模块会依赖于此协议进行组件的渲染以及交互指令的转换，所以这套页面展示协议主要包括两个部分；一部分是页面组件的渲染和编排，二部分是页面指令的转换和动作；

页面组件的渲染和编排：

首先，页面展示协议是通过Json表示的一套页面模型定义；定义中的元素可以包含展示型控件，比如表单、列表和图表，也可以包含控件型的控件，比如按钮、超链接等；控件不同的展示方式通过属性来区分开来；课参考如下实例，一个页面的定义中包含了展示型空间和控制型的控件；页面上的所有组件都是通过Control类来定义出来的，举例来说，一个用户终端的页面包括了一个列表和表单详情，则页面的模型可以定义如下：

具体的列表和表单控件内定义了需要加载的模型以及字段。在页面渲染模块中定义了一套有限的组件，比如表单，表格，卡片等组件。这里的组件就是一个前端控件的组件，一个列表的组件就是列表控件的html片段。

渲染页面协议的方法就是通过把有限的组件映射到对应的组件库中，然后在渲染的时候按照固定的格式来进行替换。具体的方式是拿到组件的模型Json，其模型Json有对应的组件属性，在按照组件的属性渲染出页面控件的html片段。

如下代码片段是一个列表页的具体html展开的方式，在运行时，会获取grid的定义属性，比如id和text html片段渲染完整。

1 const items＝data.map((grid)＝>

2 <1i key＝{grid.id}>{grid.text}

3</li>

4)；

比如如上页面渲染模块拿到此页面定义之后就可以在页面中渲染出一个表格和一个表单，并且按照竖直的方式渲染出来，列表和表单的具体属性也可以在option中获取，比如列表需要展示多少列，是否要分页

页面的指令

页面的指令是用户在页面上看到的可以交互的组件，比如一个按钮，一个连接。这类指令的交互有两种情况：

1.向后端发送一个指令，没有后续操作，比如发送一个通知

2.向后端发送一个指令，并伴随后续操作，比如打开一个页面并刷新控件内容。

页面的指令在页面展示协议中是通过action来定义出来，首先对页面的通用操作进行划分，比如根据id获取一条数据，获取一个列表数据，对数据进行更新，对数据进行删除，打开其它页面，进行一个特殊的操作。比如如下结构：

上述结构描述了一个打开页面的操作，并且其中有一个参数属性，可以放任何自定义的参数，此参数通过Json序列化成一个object，收到指令的后端可以根据指令的类型来解析对应的参数。页面渲染模块可以理解有限指令集，并且可以把对应的指令准换成对应的请求。

其中，数据动态加载模块通过定义数据模型的视图元数据来控制模型的展示逻辑，模型视图的数据定义包括视图展示的字段以及视图对应的模型筛选；

视图展示的字段是指数据视图存储的字段会保存在元数据服务中作为视图的一个部分；视图对应的模型筛选是指视图的筛选条件通过DSL把模型序列化存储，DSL的模型定义有很多方案，大多数支持查询的筛选的定义。

举例一种模型查询的DSL语音，通过Json描述；

通过如上的筛选和条件的定义，可以控制页面的列表或者表单获取对应的数据。具体的数据只需要在管理页面定义出来就可以了。

其中，元数据模块存储有包括实体、页面、视图及操作的元数据信息；

实体的元数据是业务领域模型，与数据库的表一一对应，一个实体就是一个表；业务的实体可添加业务属性；包括在实体上增加属性来标识实体是否有校验，是否和流程绑定；

页面的元数据是描述页面的组件并将组件编排的数据；

视图的元数据是实体元数据的关联数据，描述实体的过滤和查询条件，通过DSL模型进行定义和存储；

操作的元数据是领域模型对应的一个api调用，包括“下单”、“审核”等动作，实际对应一个api的调用；操作的元数据记录了调用对应的api定义。

其中，实体的元数据存储了实体模型，包括模型名称和字段，实体的模型和数据表对应的，实体的模型的变更会触发online DDL，并且改动都是在事务中保持一致性。

比如商品模型，会在元数据中定义商品(product)以及对应的字段。

1 product：

2-id

3-name

4-description

用户在管理操作中增加一个新的字段code，则会在模型元数据中会增加这一个新的字段，并且推送到数据库库中执行对应的添加列操作。然后用户就可以在api中拉取到新增列的信息。

其中，页面的元数据通过Json的方式定义出的页面模型与页面渲染模块用到的页面协议模型是一致的，并通过使用Json定义页面中用到的组件Control以及每个页面如何编排的逻辑；此外页面中还可以绑定页面指令，每一个指令都可以绑定到具体的控件中，比如可以在按钮控件中绑定一个页面的指令来跳转到其他的页面。

具体的绑定方法如下，在对应的控件会有对应的事件处理属性(比如button上会有onClick点击事件处理的函数定义)。在此基础上为对应的控件定义一个事件处理行为的属性(比如button上定义onClickAction的属性)，对应的属性中存储的就是一个操作的元数据，操作可以是rest api也可以是其它的api类型，可以根据类型来进行区分。那么对应的实际的事件处理就可以统-如下：

1.读取事件action的定义

2.翻译此定义，并执行定义中对应的请求具体的内容都在页面展示协议中描述，这里不再过多描述。

其中，视图的元数据记录了视图相关的过滤字段及条件DSL，用于在数据加载模块动态的获取视图，并且根据视图的描述来实时的加载视图指定的内容；所述数据动态加载模块使用视图元数据定义的内容来加载对应的数据。

其中，操作的元数据记录了操作对应的描述Json，操作的元数据和页面指定相对应，操作元数据可以被指定的模块转换成对应的操作

那么在运行时，逻辑执行模块就把对应的操作定义展开，并填充上具体的内容，来完成完整的api操作。

逻辑执行模块：逻辑执行模块用于响应操作元数据对应的请求，比如一个获取商品列表这样一个业务逻辑，会用上述提到操作元数据来描述之后放到具体的逻辑执行模块来把定义转换成对应的api调用。

动态修改页面和模型流程：本方案的优势是动态的修改页面和模型，不需要重新部署，下面就围绕此优势来讲述下上述的方案如何实现。当用户想调整业务逻辑，比如在订单的页面增加一个用于显示订单供应商名称的字段，需要按照如下的方式来修改：

1.修改订单模型，增加供应商字段；

2.元数据服务会增加此模型(添加供应商)字段，并执行online DDL在表中添加此字段；

3.用户修改页面，在订单页面增加此供应商字段；

4.更新操作到视图元数据，在视图筛选字段中增加供应商字段；

5.用戶重新刷新页面，看到包含供应商字段的页面

如图3所示，为用户通过一系列的api操作不需要重新部署就获得新的页面原理图。除了添加新字段外，用户还可以根据需求，调整页面的控件，把已有的数据绑定到其它的控件上，并且渲染出来，以此来满足不同场景的业务需求。此方案的好处是用户/系统定义的页面是动态的，可以根据实际的页面定义动态生成。并且通过各个模块的配合，用户可以在短时间调整或新建不同的页面，展示不同的数据，而不需要修改代码重新部署。

以上公开的本发明优选实施例只是用于帮助阐述本发明。优选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。

Claims

1.一种基于声明式组件的低代码引擎，其特征在于，该引擎包括元数据模块、数据动态加载模块、逻辑执行模块和页面渲染模块，满足用户不需要重新部署就可以调整界面、逻辑以及模型来满足自定义需求；

对于一个页面操作的数据流程如下：

S1、用户请求一个页面；

S4、动态加载模块返回具体的页面信息给前端渲染模块；

对于用户修改系统的数据流程如下：

P1、用户发送一个修改元数据的指令；

P2、修改指令通过api传递到元数据服务，元数据服务根据对应的指令进行online DDL的处理；

P6、新的页面元数据存储到数据库中；

P7、用户的更新全部完成。

2.根据权利要求1所述的一种基于声明式组件的低代码引擎，其特征在于，所述数据动态加载模块通过定义数据模型的视图元数据来控制模型的展示逻辑，模型视图的数据定义包括视图展示的字段以及视图对应的模型筛选；

3.根据权利要求1所述的一种基于声明式组件的低代码引擎，其特征在于，所述元数据模块存储有包括实体、页面、视图及操作的元数据信息；

所述页面的元数据是描述页面的组件并将组件编排的数据；

4.根据权利要求3所述的一种基于声明式组件的低代码引擎，其特征在于，所述实体的元数据存储了实体模型，包括模型名称和字段，实体的模型和数据表对应的，实体的模型的变更会触发online DDL，并且改动都是在事务中保持一致性。

5.根据权利要求3所述的一种基于声明式组件的低代码引擎，其特征在于，所述页面的元数据通过Json的方式定义出的页面模型与页面渲染模块用到的页面协议模型是一致的，并通过使用Json定义页面中用到的组件Control以及每个页面如何编排的逻辑；并且，所述页面中可绑定页面指令，每个指令均绑定于具体的控件中。

6.根据权利要求3所述的一种基于声明式组件的低代码引擎，其特征在于，所述视图的元数据记录了视图相关的过滤字段及条件DSL，用于在数据加载模块动态的获取视图，并且根据视图的描述来实时的加载视图指定的内容；所述数据动态加载模块使用视图元数据定义的内容来加载对应的数据。

7.据权利要求3所述的一种基于声明式组件的低代码引擎，其特征在于，所述操作的元数据记录了操作对应的描述Json，操作的元数据和页面指定相对应，操作元数据可以被指定的模块转换成对应的操作。