基于MyBatis的数据服务接口

背景

作为软件系统开发，数据操作是系统开发不可避免的一个重要组成部分。因为其重要性围绕着数据操作也出现了众多框架。成熟框架是为了普适众多数据操作要求的，因此为了更好的实现技术落地，需要对框架进行丰富和裁剪，适应公司业务及技术需求。本文将结合MyBatis框架进行数据服务系统设计。
结合现有的系统开发，实现一次数据操作需要有以下组成部分：

1. 定义Controller
2. 定义Menager
3. 定义Service
4. 定义Entity
5. 定义Mapper.xml
   对应一个数据操作接口，就需要定义4个方法以及1个SQLMapper。这个过程中存在较多重复的工作，给开发人员带来了工作量的，不利于系统的稳定性和。

目标

本设计的主要目标就是降低数据操作开发的复杂度，提高服务稳定性。因添加、修改、删除等一般结合较为复杂的逻辑，所以以下主要针对查询进行设计。最终实现的目标为：

1. 数据接口统一管理。
2. 对入参、出参进行统一规范。
3. 通过配置（不进行代码开发）实现数据操作。
   最终通过约定方式，实现开发人员只需要配置Mapper.xml就可以实现数据服务接口。

数据流

系统主流程为，WebApi调用后台系统，后台系统通过约定获取MyBatis的Mapper配置，生成动态SQL，实现数据操作接口。数据流如下：

1. 访问WebApi接口
2. Controller通过Token获取接口调用身份信息。
3. Controller进行接口权限验证。
4. Controller通过Body获取数据操作参数信息，映射到Map中，作为参数传入MyBatis。
5. Controller通过接口参数获取Mapper配置节点。
6. 进行数据库操作。
7. 将返回的结果根据配置进行进行映射（JS区分大小写，因此返回数据需要明确定义其Name的大小写）。
8. 序列化返回的结果。
   其中主要工作由平台完成，开发人员需要完成的工作只有以下两项：
9. 步骤5中对应的Mapper动态SQL节点的配置。
10. 步骤7中返回结果的映射配置（如数据库查询ColumnName为“platformid”，映射到返回结果时为“platfromId”）。

出入参格式

Url

Url采用同一路由，根据不同的参数（最后一部分路径），匹配不同的Mapper。
Url组成格式
''api/{系统}/{模块}/{version}/{功能}/{参数}
对应数据服务接口的Url为
''api/dbsys/dynamic/20171117/mybatis/{mytest}
相同的URL规范便于以后实现，Url与业务实现方法的动态设置匹配，实现服务发现和治理。

入参定义

Header：

1. Authorization:
2. Content-Type:application/x-www-form-urlencoded
3. ewayRequestId:GUID
4. ewayConfig:
5. ewayPlatform:{平台信息，如PlatformId,Version等}
   Body
6. param={key1:{value:value, type:type}, key2:{value:value, type:type}}
7. config=

出参定义

Body数据格式
'' {
'' requestId:’请求GUID，全局唯一，与入参ewayRequestId相同’,
'' status:200, //与http的status对应
'' code:0, //业务结果代码
'' msg:’提示信息，用于前台展示’,
'' error:’异常信息，用于异常输出’,
'' data:{返回数据信息}
'' }

后记

本文主要阐述了查询业务，对于增删改因一般存在业务流程，因此需要结合业务进行数据。
为了更好的满足产品需求，需要在平台开发方面不断完善，降低开发复杂度的同时，提供系统的扩展能力。