基于MyBatis的数据服务接口

背景

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

结合现有的系统开发，实现一次数据操作需要有以下组成部分：

1. 定义Controller
2. 定义Menager
3. 定义Service
4. 定义Entity

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

   目标

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

6. 数据接口统一管理。
7. 对入参、出参进行统一规范。

8. 通过配置（不进行代码开发）实现数据操作。
   
   最终通过约定方式，实现开发人员只需要配置Mapper.xml就可以实现数据服务接口。

   数据流

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

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

18. 步骤7中返回结果的映射配置（如数据库查询ColumnName为“platformid”，映射到返回结果时为“platfromId”）。

    出入参格式

    Url

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

    入参定义

    Header：

19. Authorization:{Token}
20. Content-Type:application/x-www-form-urlencoded
21. ewayRequestId:GUID
22. ewayConfig: {暂无，用于扩展}
23. ewayPlatform:{平台信息，如PlatformId,Version等}
    
    Body
24. param={key1:{value:value, type:type}, key2:{value:value, type:type}} {参数信息}

25. config={配置信息，主要用于增删改等业务流程配置。查询业务暂无。}

    出参定义

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

后记

本文主要阐述了查询业务，对于增删改因一般存在业务流程，因此需要结合业务进行数据。

为了更好的满足产品需求，需要在平台开发方面不断完善，降低开发复杂度的同时，提供系统的扩展能力。