基于MyBatis的数据服务接口
背景
作为软件系统开发，数据操作是系统开发不可避免的一个重要组成部分。因为其重要性围绕着数据操作也出现了众多框架。成熟框架是为了普适众多数据操作要求的，因此为了更好的实现技术落地，需要对框架进行丰富和裁剪，适应公司业务及技术需求。本文将结合MyBatis框架进行数据服务系统设计。
结合现有的系统开发，实现一次数据操作需要有以下组成部分：
- 定义Controller
- 定义Menager
- 定义Service
- 定义Entity
- 定义Mapper.xml
对应一个数据操作接口，就需要定义4个方法以及1个SQLMapper。这个过程中存在较多重复的工作，给开发人员带来了工作量的，不利于系统的稳定性和。
目标
本设计的主要目标就是降低数据操作开发的复杂度，提高服务稳定性。因添加、修改、删除等一般结合较为复杂的逻辑，所以以下主要针对查询进行设计。最终实现的目标为：
- 数据接口统一管理。
- 对入参、出参进行统一规范。
- 通过配置（不进行代码开发）实现数据操作。
最终通过约定方式，实现开发人员只需要配置Mapper.xml就可以实现数据服务接口。
数据流
系统主流程为，WebApi调用后台系统，后台系统通过约定获取MyBatis的Mapper配置，生成动态SQL，实现数据操作接口。数据流如下：
- 访问WebApi接口
- Controller通过Token获取接口调用身份信息。
- Controller进行接口权限验证。
- Controller通过Body获取数据操作参数信息，映射到Map中，作为参数传入MyBatis。
- Controller通过接口参数获取Mapper配置节点。
- 进行数据库操作。
- 将返回的结果根据配置进行进行映射（JS区分大小写，因此返回数据需要明确定义其Name的大小写）。
- 序列化返回的结果。
其中主要工作由平台完成，开发人员需要完成的工作只有以下两项： - 步骤5中对应的Mapper动态SQL节点的配置。
- 步骤7中返回结果的映射配置（如数据库查询ColumnName为“platformid”，映射到返回结果时为“platfromId”）。
出入参格式
Url
Url采用同一路由，根据不同的参数（最后一部分路径），匹配不同的Mapper。
Url组成格式
''api/{系统}/{模块}/{version}/{功能}/{参数}
对应数据服务接口的Url为
''api/dbsys/dynamic/20171117/mybatis/{mytest}
相同的URL规范便于以后实现，Url与业务实现方法的动态设置匹配，实现服务发现和治理。
入参定义
Header：
- Authorization:
- Content-Type:application/x-www-form-urlencoded
- ewayRequestId:GUID
- ewayConfig:
- ewayPlatform:{平台信息，如PlatformId,Version等}
Body - param={key1:{value:value, type:type}, key2:{value:value, type:type}}
- config=
出参定义
Body数据格式
'' {
'' requestId:’请求GUID，全局唯一，与入参ewayRequestId相同’,
'' status:200, //与http的status对应
'' code:0, //业务结果代码
'' msg:’提示信息，用于前台展示’,
'' error:’异常信息，用于异常输出’,
'' data:{返回数据信息}
'' }
后记
本文主要阐述了查询业务，对于增删改因一般存在业务流程，因此需要结合业务进行数据。
为了更好的满足产品需求，需要在平台开发方面不断完善，降低开发复杂度的同时，提供系统的扩展能力。
