一种跨平台、多语言的ORM服务框架解决方案的制作方法

一种跨平台、多语言的orm服务框架解决方案
技术领域
1.本发明属于计算机技术领域，尤其涉及一种跨平台、多语言的orm服务框架解决方案。


背景技术：

2.orm是对象关系映射(object-relational mapping)的简称，是一种编程技术，通常在oop(object-oriented programming)面向对象编程的时候，为了解决对象的持久化到数据库的操作更简便，并且不破坏oop编程范式的规范而存在的一种编程思想框架。其目标是将面向对象的数据模型和关系数据库之间进行映射，使得程序可以像操作对象的常规方式一样操作对象的持久化到数据库，而不需要直接编写sql语句。
3.各个公司it选择的orm框架都各不相同，大多数因为开发语言的基础，在可选的几个框架中选用一个进行使用。当公司多个业务本身就是多种语言的时候，那么就可能出现一家公司会使用2种或者更多种orm框架的情况。
4.例如某公司财务系统，一部分是使用java web技术，一部分业务使用c#.net技术，那么就可能存在即使用java hibernate又用c#的entity framework这两个orm框架。甚至还会有前端javascript、python后端脚本、rust、scala等的业务也要用，导致选用的orm框架越来越多；
5.由于引入的orm框架多了，对技术人员的学习、开发、维护、升级成本都变得高了；各种orm框架的配置细节不一样，功能特点不一样，缓存策略不一样，连接池支持和使用方法也不一样，字段约束/定义也不一样。导致整个学习周期变长，特别是针对那些少数员工但是要进行全栈业务开发的，仅多个orm的用法都需要花费他个人不少的时间；另外即使开发上线了，那么后期的维护、变更、升级，都会带来更多不可想象的细节问题，严重者可能引起部分业务无法运行。


技术实现要素：

6.有鉴于此，本发明基于kinedb提供了一种跨平台、多语言的orm服务框架解决方案，以解决现有技术中由于引入的orm框架多了，技术人员的学习、开发、维护、升级成本变高的问题。
7.本发明提供了一种跨平台、多语言的orm服务框架解决方案，包括以下步骤：
8.步骤s1：抽象orm的逻辑为grpc跨语言的接口定义，grpc定义生成不同语言版本的client，grpc对于服务端的接口定义生成不同语言的客户端代码；
9.步骤s2：对于步骤s1中不同语言的客户端代码，创建对应的客户端，针对不同客户端语言封装thin wrapper轻量客户端；
10.步骤s3：使用grpc的message指令定义表结构，生成语言的类，并将类对象操作当做表记录对象；
11.步骤s4：使用grpc的service rpc指令定义orm操作接口所必需的数据结构；
12.步骤s5：使用grpc的service rpc指令定义orm的操作接口；
13.步骤s6：对表数据的crud(指在做计算处理时的增加create、读取read、更新update和删除delete)进行操作。
14.进一步地，如权利要求1所述的一种跨平台、多语言的orm服务框架解决方案，其特征在于，所述步骤s4具体如下：
15.步骤s41：grpc使用message指令定义数据库连接connection数据结构，结构体中包含数据库连接的唯一编号、用户名、密码、访问的数据库名称和访问的数据库实例地址url；
16.步骤s42：grpc使用message指令定义数据库操作会话session数据结构，结构体中包含会话唯一编号、会话的可选配置属性map《属性名,属性值》集合；
17.步骤s43：grpc使用message指令定义一个事务实例transaction数据结构，结构体中包含事务唯一编号，事务的可选设置参数map《参数名，参数值》集合；
18.步骤s44：grpc使用message指令定义统一的错误kierror数据结构，结构体包含错误码、状态码和错误信息描述。
19.进一步地，所述步骤s5包括以下步骤：
20.步骤s50：grpc使用service rpc指令来定义打开数据库会话opensession操作，该操作参数为connection连接对象，表示访问的是对应连接所描述地址的数据库。返回值就是一个会话session实例，会话session保存了当前会话的编号和一些会话属性。
21.步骤s51：grpc使用service rpc指令来定义关闭数据库会话closesession操作，该操作参数传入session会话对象，表示关闭的是session所描述的会话编号对应的会话内容。操作的返回值是kierror错误码，若关闭会话报错，则会返回错误，否则错误码为空。
22.步骤s52：grpc使用service rpc指令来定义开始事务begintransaction操作，该操作传入参数是session对象，表示在这个会话上开启一个事务。操作的返回值就是一个transaction事务实例对象，用于表示这个事务上下文信息。
23.步骤s53：grpc使用service rpc指令来定义提交事务committransaction操作，该操作传入的参数是transaction事务对象，表示把这个事务所关联的系列操作作为一个事务提交。该操作的返回值是kierror统一错误码，表示事务提交是否正确。
24.步骤s54：grpc使用service rpc指令来定义回滚事务rollbacktransaction操作，该操作传入的参数是transaction事务对象，表示把这个事务所关联的系列操作回滚，操作的返回值是kierror，表示是否回滚成功。
25.步骤s55：grpc使用service rpc指令来定义关闭事务closetransaction操作，表示关闭此事务的操作，释放此事务相关的资源。该操作的返回值是kierror表示是否关闭成功。
26.进一步地，所述步骤s5还包括
27.步骤s56：grpc使用service rpc指令来定义保存对象save操作，该操作的传入参数为会话session和对象实例，表示将此对象作为一条记录保存到数据库中。操作返回值为kierror，表示操作成功与否。
28.步骤s57：grpc使用service rpc指令来定义更新对象update操作，该操作的传入产生为session会话和对象实例，表示将此对象实例更新到数据库对应记录中。操作返回值
为kierror，表示操作成功与否。
29.步骤s58：grpc使用service rpc指令来定义删除对象delete操作，该操作的传入产生为session会话和对象实例id唯一编号，表示将此对象实例id的记录从数据库中删除。操作返回值为kierror，表示操作成功与否。
30.步骤s59：grpc使用service rpc指令来定义查询对象get操作，该操作的传入产生为session会话和过滤条件，表示从数据库中查询出满足条件的对象来。
31.进一步地，所述步骤s6具体如下：
32.步骤s60：在生成的“打开会话opensession(connection)接口的代码”中，填入实现逻辑如下：
33.验证用户，并打开连接，然后服务端创建一个会话session结构，并返回；
34.步骤s61：在生成的“关闭会话closesession(session)接口的代码”中，填入实现逻辑如下
35.验证本地会话是否存在，若存在且未关闭，则关闭会话；
36.步骤s62：在生成的“开始事务begintransaction(session)接口的代码”中，填入实现逻辑如下：
37.找打当前会话session，根据会话上下文信息，开启一个transaction事务实例，并返回事务id相关标志信息；
38.步骤s63：在生成的“提交事务committransaction(transaction)接口的代码”中，填入实现逻辑如下
39.根据transaction中的事务编号，找到对应真实的事务实例，并调用其commit接口执行真实的事务提交操作，并返回执行状态信息；
40.步骤s64：在生成的“回滚事务rollbacktransaction(transaction)接口的代码”中，填入实现逻辑如下
41.根据transaction中的事务编号，找到对应真实的事务实例，并调用其rollback接口执行真实的事务回滚操作，并返回执行状态信息；
42.步骤s65：在生成的“关闭事务closetransaction(transaction)接口的代码”中，填入实现逻辑如下
43.根据transaction中的事务编号，找到对应真实的事务实例，调用其close接口执行真实的事务上下文资源释放操作，并返回执行状态信息；
44.进一步地，所述步骤s6还包括：
45.步骤s66：在生成的“保存对象save(session,any)接口的代码”中，填入实现逻辑如下
46.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，然后把对象信息写入到对应的库表中，作为一条记录保存，并返回执行状态信息；
47.步骤s67：在生成的“更新对象update(session,any)接口的代码”中，填入实现逻辑如下
48.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，然后把对象信息更新到对应的库表中，并返回执行结果；
49.步骤s68：在生成的“删除对象delete(session,any)接口的代码”中，填入实现逻
辑如下
50.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，然后把对象编号所代表的记录，从对应库表中删除，并返回执行结果；
51.步骤s69：在生成的“查询对象get(session,any,filter)接口的代码”中，填入实现逻辑如下
52.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，再解析filter为对象筛选条件，最后从这个表里筛选满足对应筛选条件的对象记录出来，并返回。
53.进一步地，还包括自定义实现一个start service启动服务的接口。
54.与现有技术相比，本发明有益效果是：
55.1.本发明提供的一种跨平台、多语言的orm服务框架解决方案，通过提出使用跨语言协议来定义库表结构、定义通用orm对象操作接口，支持多语言设计架构思路。
56.2.本发明提供的一种跨平台、多语言的orm服务框架解决方案，内置连接池，通过kiorm服务端的链接池保持，来降低客户端请求处理时建立链接所需要的时间。
57.3.本发明提供的一种跨平台、多语言的orm服务框架解决方案，缓存通过kiorm的服务端实现，客户端并不保存任何数据缓存，从而降低客户端的压力，外一方面，也能够让多客户端的相同查询，能够复用相同的查询缓存结果。进而提升内存利用率，也提高客户端的请求体验和稳定性。
附图说明
58.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
59.图1为本发明的流程示意图；
60.图2为本发明方法步骤图；
61.图3为本发明架构的数据流图；
62.图4-5为本发明中定义表的示意图；
63.图6为本发明的代码示例图；
64.图7为现有技术的流程示意图。
具体实施方式
65.下面结合附图对本发明作进一步地详细说明，但是本发明的实施方式不限于此。
66.首先对本发明中出现的专业语言作如下解释：
67.kinedb：是一个自研的分布式、多数据源、联邦计算引擎。它是mpp的架构，但又不同于传统presto/spark计算引擎，它具备ap/tp融合计算，并且提供统一sql/gql客户端查询语言，操作各种异构数据源；
68.rpc：rpc是远程过程调用(remote procedure call)的缩写形式，一般指远程过程调用。
69.oop：是面向对象编程(object-oriented programming)的缩写。它是一种编程范式或编程风格，其中的代码和数据被组织为对象，对象可以与其他对象进行交互，从而构建出复杂的软件系统。oop的特点包括封装、继承、多态等；
70.orm：是对象关系映射(object-relational mapping)的缩写。它是一种编程技术，将oop面向对象编程语言和关系型数据库之间的映射自动化，从而方便开发人员在程序中使用对象来操作数据库，而无需直接编写sql语句；
71.跨平台：指的是软件能够在多种操作系统或硬件平台上运行。在跨平台软件开发中，开发人员需要编写一份代码，然后通过编译或解释器将其转换为多个不同平台上的可执行文件。
72.多语言：指的是在软件开发中使用多种编程语言来编写不同部分的代码。在大型软件系统中，通常需要使用多种编程语言来实现不同的功能，例如使用c 编写系统底层代码、使用java编写web应用程序、使用python编写数据处理程序等。多语言开发可以充分发挥不同编程语言的优势，提高软件的效率和可靠性；
73.grpc：是一个现代的开源高性能远程过程调用(rpc)框架，可以在任何环境中运行；
74.thrift：是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务。它被当作一个远程过程调用(rpc)框架来使用；
75.protocol buffers：是google开源的一种独立的数据交换格式，它独立于语言，独立于平台，可运用于多种领域应用的数据交换上；
76.avro：是指数据序列化的系统，有丰富的数据结构类型、快速可压缩的二进制数据形式。主要是用在通用数据格式的表示和交换上；
77.kiorm：这是本专利orm方案的命名kiorm，意思是kinedb orm项目的简称。
78.如图1和图2所示，本发明提供了一种跨平台、多语言的orm服务框架解决方案，包括以下步骤：
79.步骤s1：抽象orm的逻辑为grpc跨语言的接口定义，grpc定义生成不同语言版本的client，grpc对于服务端的接口定义生成不同语言的客户端代码；
80.步骤s2、对于步骤s1中不同语言的客户端代码，创建对应的客户端，针对不同客户端语言封装thin wrapper轻量客户端；
81.步骤s3：使用grpc的message指令定义表结构，生成语言的类，并将类对象操作当做表记录对象；
82.步骤s4：使用grpc的service rpc指令定义orm操作接口所必需的数据结构；
83.步骤s5：使用grpc的service rpc指令定义orm的操作接口；
84.步骤s6：对表数据的crud进行操作。
85.如图3所示展示了图1架构中query1业务查询进行时，本技术架构的数据流图情况如下：
86.流程1：各种业务模块请求参数，转换为对应版本轻客户端的user对象；
87.流程2：thin wrapper client各个版本的轻客户端，实际调用user对象的查找方法；
88.流程3：grpc统一定义协议模块，进行grpc框架的协议通信，远程调用kiorm的对应
接口；
89.流程4：kiorm服务端解析grpc请求，这里为user查询请求，则进行user表的实际查询，并返回结果。
90.使用grpc定义一张表，假设我们有一张表person如图4所示，而使用grpc定义的表结构如图5所示，
91.如图4，图5上代码看出，利用grpc的方式定义一张表，使用这个定义，就可以生成java/rust/c /go/python等语言的类了，从而利用这个类对象来操作当做表记录对象，这样就解决了多语言的各种字段映射不准确、不统一的问题，大大降低了orm在跨平台、多语言的场景使用；
92.orm框架是对object对象的数据库持久化操作的编程框架，核心把对象存储到数据库中，以及从数据库从查询出来。另外还会包含一下数据库场景操作的接口，例如事务、分页等。这里把几个最核心的接口通过grpc的service rpc定义出来，如下：
93.以下通过gprc message定义通用orm操作接口所必需的数据结构：会话、连接、事务、错误码，
94.步骤s41：grpc使用message指令定义数据库连接connection数据结构，结构体中包含数据库连接的唯一编号、用户名、密码、访问的数据库名称和访问的数据库实例地址url；
95.步骤s42：grpc使用message指令定义数据库操作会话session数据结构，结构体中包含会话唯一编号、会话的可选配置属性map《属性名,属性值》集合；
96.步骤s43：grpc使用message指令定义一个事务实例transaction数据结构，结构体中包含事务唯一编号，事务的可选设置参数map《参数名，参数值》集合；
97.步骤s44：grpc使用message指令定义统一的错误kierror数据结构，结构体包含错误码、状态码和错误信息描述。
98.以下通过gprc service rpc定义通用orm操作接口
99.步骤s50：grpc使用service rpc指令来定义打开数据库会话opensession操作，该操作参数为connection连接对象，表示访问的是对应连接所描述地址的数据库。返回值就是一个会话session实例，会话session保存了当前会话的编号和一些会话属性。
100.步骤s51：grpc使用service rpc指令来定义关闭数据库会话closesession操作，该操作参数传入session会话对象，表示关闭的是session所描述的会话编号对应的会话内容。操作的返回值是kierror错误码，若关闭会话报错，则会返回错误，否则错误码为空。
101.步骤s52：grpc使用service rpc指令来定义开始事务begintransaction操作，该操作传入参数是session对象，表示在这个会话上开启一个事务。操作的返回值就是一个transaction事务实例对象，用于表示这个事务上下文信息。
102.步骤s53：grpc使用service rpc指令来定义提交事务committransaction操作，该操作传入的参数是transaction事务对象，表示把这个事务所关联的系列操作作为一个事务提交。该操作的返回值是kierror统一错误码，表示事务提交是否正确。
103.步骤s54：grpc使用service rpc指令来定义回滚事务rollbacktransaction操作，该操作传入的参数是transaction事务对象，表示把这个事务所关联的系列操作回滚，操作的返回值是kierror，表示是否回滚成功。
104.步骤s55：grpc使用service rpc指令来定义关闭事务closetransaction操作，表示关闭此事务的操作，释放此事务相关的资源。该操作的返回值是kierror表示是否关闭成功。
105.步骤s56：grpc使用service rpc指令来定义保存对象save操作，该操作的传入参数为会话session和对象实例，表示将此对象作为一条记录保存到数据库中。操作返回值为kierror，表示操作成功与否。
106.步骤s57：grpc使用service rpc指令来定义更新对象update操作，该操作的传入产生为session会话和对象实例，表示将此对象实例更新到数据库对应记录中。操作返回值为kierror，表示操作成功与否。
107.步骤s58：grpc使用service rpc指令来定义删除对象delete操作，该操作的传入产生为session会话和对象实例id唯一编号，表示将此对象实例id的记录从数据库中删除。操作返回值为kierror，表示操作成功与否。
108.步骤s59：grpc使用service rpc指令来定义查询对象get操作，该操作的传入产生为session会话和过滤条件，表示从数据库中查询出满足条件的对象来。
109.如上所述，包含所有orm必须包含的数据库链接，session的会话保持，transaction的事务操作，这些都是通用的orm操作，蒋其抽象定义成了通用的协议，如此，所有的多语言客户端都可以使用统一的接口来完成kiorm交互操作，从而实现面向对象的数据库持久化相关操作；
110.通过上述的定义文件，可以生成任何语言的service服务端接口代码，采用go语言展示说明，这里的服务名称命名就是kiorm服务，如下为grpc定义接口生成的服务端接口具体实现步骤描述：
111.步骤s60：在生成的“打开会话opensession(connection)接口的代码”中，填入实现逻辑如下：
112.验证用户，并打开连接，然后服务端创建一个会话session结构，并返回；
113.步骤s61：在生成的“关闭会话closesession(session)接口的代码”中，填入实现逻辑如下
114.验证本地会话是否存在，若存在且未关闭，则关闭会话；
115.步骤s62：在生成的“开始事务begintransaction(session)接口的代码”中，填入实现逻辑如下：
116.找打当前会话session，根据会话上下文信息，开启一个transaction事务实例，并返回事务id相关标志信息；
117.步骤s63：在生成的“提交事务committransaction(transaction)接口的代码”中，填入实现逻辑如下
118.根据transaction中的事务编号，找到对应真实的事务实例，并调用其commit接口执行真实的事务提交操作，并返回执行状态信息；
119.步骤s64：在生成的“回滚事务rollbacktransaction(transaction)接口的代码”中，填入实现逻辑如下
120.根据transaction中的事务编号，找到对应真实的事务实例，并调用其rollback接口执行真实的事务回滚操作，并返回执行状态信息；
121.步骤s65：在生成的“关闭事务closetransaction(transaction)接口的代码”中，填入实现逻辑如下
122.根据transaction中的事务编号，找到对应真实的事务实例，调用其close接口执行真实的事务上下文资源释放操作，并返回执行状态信息；
123.步骤s66：在生成的“保存对象save(session,any)接口的代码”中，填入实现逻辑如下
124.找到会话是表示的数据库连接，解析any(目标)为具体某个对象类型，得到其所代表的库表名字，然后把对象信息写入到对应的库表中，作为一条记录保存，并返回执行状态信息；
125.步骤s67：在生成的“更新对象update(session,any)接口的代码”中，填入实现逻辑如下
126.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，然后把对象信息更新到对应的库表中，并返回执行结果；
127.步骤s68：在生成的“删除对象delete(session,any)接口的代码”中，填入实现逻辑如下
128.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，然后把对象编号所代表的记录，从对应库表中删除，并返回执行结果；
129.步骤s69：在生成的“查询对象get(session,any,filter)接口的代码”中，填入实现逻辑如下
130.找到会话是表示的数据库连接，解析any为具体某个对象类型，得到其所代表的库表名字，再解析filter为对象筛选条件，最后从这个表里筛选满足对应筛选条件的对象记录出来，并返回。
131.图6展示了grpc自动生成的opensession代码，从图6代码我们可以看到，整个client是非常轻的，不需要实现任何的orm处理逻辑，所有的逻辑都变成普通的grpc请求kiorm服务来执行，而且代码是grpc直接生成的，对于接口请求交互上，完全不需要开发代码。在使用的时候只需要使用其newkiormserviceclient即可与kiorm service通信。这种做法，不管是各种语言，都可以得到一致使用体验、一致的功能列表、一致的性能表现。
132.挑选了几个代表性框架和几个代表性功能项对比如下表所示，
133.134.[0135][0136]
表格中：
[0137]
适用语言：表示什么语言可以使用此orm框架；
[0138]
开源协议：表示是否开源，及其开源遵从的协议；
[0139]
连接池：orm框架是否支持连接池，是内置还是第三方的方式支持；
[0140]
预编译：即sql是否支持对象操作预编译，例如prepare语法"select*from xx where col1＝？"；
[0141]
缓存:即查询缓存是否支持，有的orm框架提供了这方面查询结果的缓存，并提供一些缓存更新、失效策略配置；
[0142]
数据库迁移：即数据库表结构变更，orm框架是否支持自动修改表结构；
[0143]
分页：是否支持业务的分页查询操作；
[0144]
事务：是否支持事务操作；
[0145]
关联对象操作：关联对象的一对一、一对多、多对多操作是否支持；
[0146]
支持数据库：表示此orm框架支持哪些关系数据库存储；
[0147]
自动生成sql：有些orm框架需要手动写操作对象的sql，有些则不需要。例如hibernate复杂sql要手写，mybatis查询时都需要手写；
[0148]
数据验证：是否支持数据字段的格式、类型校验、长度、大小限制的校验。这里主要指业务逻辑约束这方面；
[0149]
扩展支持新数据库：是否可以通过扩展插件形式，支持更多特定的数据库。主要指框架本身是否有plugin、adapter方式支持扩展额外特定数据库对接。
[0150]
如上表所示，本方案有如下有益效果：
[0151]
(1)支持多语言，通过提出使用跨语言协议来定义库表结构、定义通用orm对象操作接口，来体现跨平台、跨语言的设计架构思路，
[0152]
(2)内置连接池，通过kiorm服务端的链接池保持，来降低客户端请求处理时建立链接所需要的时间，作为orm服务端，完全可以实现任何数据库的链接池功能；
[0153]
(3)完全可以实现这个对象操作的预编译sql功能。
[0154]
(4)缓存通过kiorm的服务端实现，客户端并不保存任何数据缓存，从而降低客户端的压力。另外一方面，也能够让多客户端的相同查询，能够复用相同的查询缓存结果。进而提升内存利用率，也提高客户端的请求体验和稳定性；
[0155]
(5)不支持数据库迁移，由于库表结构变更时，各个orm框架会引发很多修改和变更测试，可能会有额外的bug引入。kiorm提倡结构变更尽可能少，如果要修改，则通过grpc通用定义修改其表结构重新生成客户端api来给客户端升级使用，简单来说就是表结构迁移升级变成通过静态的grpc定义来实现，而不是动态的代码来修改表结构。如果动态的修改，可能会导致各个业务的orm代码执行发生bug异常，所以我们把这个库表变更的事情，前置到静态定义的层次上，让用户做变更的时候，就感知到这个变化，并为这个变化做出系列重新定义和统一替换各种thin wrapper客户端的工作，进而极大降低各个业务出现未知bug的可能性；
[0156]
(6)通过kiorm方案，分页是通过客户端持有的session中的query id以及offset信息，请求时携带到kiorm服务端，服务端通过常规的数据库分页技术offset、limit来访问对应的数据库来实现；
[0157]
(7)事务：通过session/transaction来保持会话的事务id，每次请求的时候都携带这些信息和对应的sql到服务端，服务端根据transaction id信息维护各自的事务，包括开启事务、执行sql、提交事务、回滚事务操作；
[0158]
(8)支持数据库：由于本方案设计kiorm服务端是可以自定义实现的，完全可以实现任何关系数据库的对接使用，这部分并不展开阐述，因为到了kiorm服务端代码的实现，可以是非常灵活、任意自定义的，所以对接任何的关系数据库都是可行的；
[0159]
(9)数据验证：关于数据约束，这里也是可以定义约束的，在声明grpc的时候，定义对应的关联约束。在kiorm服务端代码中，使用这些约束来进行统一的字段值约束。从方案技术层面看，完全可以定义实现数据验证功能的；
[0160]
(10)扩展数据库：支持扩展，因为kiorm服务端代码可以灵活自定义实现，完全可以介入任何新的数据库，例如tidb等，甚至对接一些非关系数据库。
[0161]
如图1所示，可以看到当多个编程语言业务使用orm、相同语言多个client使用orm
的请求，只要是相同的查询，那么查询缓存只会有一份query cache result。对于服务端来说，这极大的降低了多客户端重复查询的压力，提升了查询缓存的利益率。从客户端来说，也降低了各种缓存查询数据的压力，相比如现有技术，图7所示，客户端不再缓存查询结果，而是又统一的orm服务端进行缓冲，降低了客户端的压力，进而提升客户端的运行性能和稳定性。
[0162]
另外，对于其他连接池功能也类似，若按照图6的方案，每个client都会有连接池，如果client变得很大，那么这个链接也是会变得过多。而kiorm的方案则吧链接池维护在服务端，客户端只需要维护对应的会话即可，具体操作到服务端时，由kiorm服务端进行选用和维护连接池。从这个方面也是降低了链接的个数，降低了对数据库链接的维护压力。
[0163]
当公司各种业务涉及多语言开发时，会涉及多个orm框架时，会导致技术架构复杂，各种orm组件太多，学习/维护/升级成本都变高，且每个orm框架对字段的映射准确性和类型定义都不一样。但是使用了kiorm方案后，这些问题都能得到很好的解决。例如：一个kiorm框架替换多种语言的orm框架，架构简单，学习/维护多个orm的成本也降低到仅维护1个orm框架的成本上。另外，多语言环境下，字段的映射准确性和类型定义都完全一致，这就使得一个公司的各种业务操作数据库的逻辑接近相同。
[0164]
若后续需要扩展更多功能，只需要相应修改grpc定义的通用协议，并实现对应kiorm服务代码，并重新生成thin wrapper客户端就可以直接使用。比如orm缓存、分页、连接池等，都是可以通过类似方式实现一整套链路功能，这里不再累赘。
[0165]
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。