入职之初就在思考,如何在现有框架下实现 api 开发的自动化,因为只做请求转发的话,业务重复性太高,如果不抽象出来比较可惜
思路
- 针对相同的业务做一系列约定(变量、业务步骤)
- 应该分离变与不变, 不变的部分应该可以直接生成,变化很少的部分应该可以实现外部登记,变化很多的地方要么暴露接口,要么再作分离
目标
- 接口应该有通行的解决方案(业务处理步骤)
- 接口参数应该可以实现可配置
- 终极目的是为了快速迭代开发
- 应留下一定的可扩展性(以应对需求的变化)
关于数据源返回值处理
1.默认数据源返回的是一个数组,应该可以用类似
'data.realname ' => 'response.data.name'
的方式实现映射,用点来分离数组嵌套,用key
,value
实现最终返回值对数据源返回值的映射关系2.异常逻辑如何定义,一是针对特定域特定值的处理,如数据源
code
等于-1
,那么返回异常;另一个是针对无值的处理,如压根没有code
域,或者返回的字符串不是json格式3.数据处理步骤如何组织,有些非通用步骤,如有的需要 Rsa ,有的需要DES,有的需要
json_decode
,有的需要再调用其他接口获取token
,这里可以考虑实现一个 Decoration ,留下接口让他们自己玩吧,反正最后返回一个数组(对象)就可以了4.关于错误码管理,错误码应该是一个全局的配置,因为在数据源调度类和数据源的业务类都会涉及到这些业务,但是错误逻辑是没法枚举的,此处应该可以让后续的开发者自己扩展(不是hard code扩展)
自动化任务解决哪些痛点
1.少写一点是一点,包括字段映射的部分,包括存入日志和缓存库构造的数组
2.之前通过复制解决的问题,尽量用自动化的方式
3.数据源调度类和数据源业务类的逻辑分离
通用函数库
- 字段映射
- http
- autoload
- decentDump
数据源调度类解决的问题
- 1.构造函数 -> 获取 did 、key ,初始化开始时间
- 2.获取参数
- 3.参数校验 -> 参数校验组件 (传入数组并配置规则)-> 全局错误码管理
- 4.从db获取数据 -> 配置需要的字段数组 -> fetcher 组件
- 5.db如果取得数据,此处应该也有字段映射->函数实现
- 6.数据源管理 -> 数据源字符串替换
- 7.日志记录功能 -> 一部分参数是系统自带,另外一部分参数是映射 ->函数实现(可能为空)
- 8.数据返回功能 -> 复制吧