一种基于SpringMVC的通用控制器接口层简化实现方案

基于SpringMVC的通用接口简化实现方案

一、问题的引出

SpringMVC实现了在web开发中，模型-视图-控制器的分离开发。在视图层，开发者关注的数据的呈现，在模型层，开发者关注的是数据的输入输出的结构。通过控制器层，将模型和视图进行数据的关联以及逻辑的绑定。

• Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器；
• View（视图） - 视图代表模型包含的数据的可视化；
• Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图，它使得视图与模型分离。

MVC的关系示意图

往往随着系统的功能逐步复杂，尤其是前后端分离的开发模式的兴起，基于RestApi风格的数据接口逐步成为主流，相对于Controller层来说，结构趋于一致，较为复杂的逻辑也下沉到业务逻辑层完成。往往对于结构变化不大的数据接口定义，显得越来越臃肿。
如：

针对不同的URL路径，要独立定义一个Controller控制器类，或者在Controller控制器类中，扩充一个方法将url路径映射与具体的执行逻辑实例方法进行关联，开发过程中，显得繁琐，而且一旦方法增多，也不利于url映射关系的集中管理。

二、解决方案

为解决Controller层臃肿的问题，便于集中管理路径，这里采用了一种基于SpringBean管理的泛化绑定方案，即统一定义一个集合，包含url与具体执行方法的映射关系。通过SpringMVC的匹配方法，实现url请求到具体的业务逻辑，返回逻辑层执行数据。

第一步：定义关系实体

这里定义的实体只是实例，可以在其基础上，扩充其他业务字段，如接口描述备注，上下线状态，权限控制，日志信息，调用次数等额外信息，可根据实际业务场景进行选择。

第二步：定义Controller映射关系

定义url配置类：
需要说明的是，这里将基础配置关系采用list集合定义，未来根据需要，也可以将其写入到配置文件中，能够方便维护。或者存入到数据库中，就可以实现接口关系的动态的维护了。

第三步：定义Spring上下文工具类

这里定义一个工具方法，通过这个工具方法，使用反射的方式，得到Spring容器中，所有被@Service注解所标记的类实例。这里根据类型从容器中匹配得到其实例。

第四步：定义通用Controller调用方法

1.根据/api/**，匹配对应的路径；
2.获取请求参数；
3.获取url配置关系；
4.解析全类名方法名；
5.通过容器工具得到需要执行的类实例；
6.得到实例方法；
7.装配转换入参；
8.调用方法执行返回。

到这里为止，通过4步方法，通用控制器实现完成，通过POSTMAN接口工具，观察执行效果。

三、结果展示

1：业务逻辑层定义

业务逻辑方法，这里编写一个业务逻辑，模拟获取数据，其内容为： {“data”:“demo1”}，同时打印日志。

2：启动应用

观察启动日志，/api/**已经随应用启动被加载。

3：发送请求

使用postman发送请求，请求格式为JSON方式，观察报文正确返回

4：后端日志

后端日志，正确显示出请求的参数。真实开发中，要根据实际业务，对参数进行处理，返回真实的业务逻辑数据。

四、小结

本文通过在业务系统开发中，接口规模变大，遇到的控制层臃肿的问题，提出了一套控制层简化实现方案，其核心思想是采用将视图和数据的绑定过程，交给配置文件，或持久化到系统外部，通过SpringBean核心容器工具方法，实现逻辑调用，返回业务数据。
通过改造后，能够实现既定目标，借助于泛化调用，简化了控制器层的开发。但随着业务系统的复杂多变，使用场景的不确定性，仍需要根据实际场景进行选择。

需要注意的是：
1.如果系统规模本身不大，接口数量也不是很多，通过构造统一通用的方法显得有些复杂；通常接口规模数量到达一定程度的时候，该方案优势才能体现得比较明显；
2.依据TTD开发思想，在完成业务逻辑方法后，可对业务逻辑层进行单独测试验证；因为控制器层已经标准通用化不再做改变，也降低了控制器层的测试成本。在接口定义层，如果需要Mock数据，仅需要定义不同的mock方法，而保持url路径相对稳定，也便于前后端分离场景下的整体协作开发；
3.在分布式微服务场景下，结合RPC本身支持的泛化调用，可独立出接口网关实现权限控制，日志管理，接口聚合，服务降级等更多操作，系统可根据实际情况做调整。

写在2020.6.1儿童节之际，愿每一个保持童真般的求知欲和好奇心的宝宝被这个世界所善待。