一、前后端怎样协作?
后端:
(1)开发阶段,接口频繁变更,每次文档都要更新?好烦。。。
(2)接口文档格式五花八门,完全统一准确无误?好难。。
(3)维护文件费时费力还不算产出,毫无动力。。
前端:
(1)接口文档几乎没见过更新
(2)找接口得直接找对口人
于是乎… QQ成为后端联调的主要工具。
问题:
(1)知识不能积淀下来!!!最终接口文档不能从天上掉下来!!!
(2)沟通难免有歧义,调用方式、参数易用错,bug频发!!!
(3)后人维护困难!!!
如何解决?
(1)根据代码生成接口文档!Springfox + Swaggger UI
(2)引入成本:只在现有业务Controller上加一点注解!!!
(3)怎么实现:且听下回分解
二、 Controller怎么重构?
现在的Controller都做了什么?
(1)打印入参log
(2)对参数长度、格式进行校验,若不过则给FE返回参数错误提示
(3)对参数进行业务校验,若通不过则给FE返回业务校验错误提示
(4)调用业务Service,获得返回值
(5)若Service异常,则记录log并给FE返回异常提示
(6)打印出参log
(7)给FE返回结果JSON数据
但是存在问题:
(1)面面俱到,但职责不单一,Controller里业务无关的代码太多。
(2)单靠约定,并不是所有人都可以如此规范、面面俱到。
(3)对参数长度、格式的校验太过繁琐。
(4)通过返回值返回Service中的业务校验结果太复杂
(5)千篇一律的参数打印、异常处理、FE数据返回
(6)不一致的log输出格式,后期自动化分析和自动报警困难
重构:Controller单个方法代码行数减少50%
(1)自动打印Controller的入参和出参,统一规范,业务Controller里不用再手写log了
(2)使用JSR303对参数进行预校验,不用手写代码判断字符串长度、空串等了。
(3)业务Controller里不再需要对JSR303校验结果和业务校验结果进行判断和返回FE了。
(4)统一处理参数异常、业务异常和系统异常,自动打印异常栈,并返回FE异常提示
(5)统一给FE返回数据,业务Controller的方法返回VO即可,不用手动调用responseJsonp
(6)业务Controller里依旧可以打log,处理异常,无影响。

690

被折叠的 条评论
为什么被折叠?



