权限抽象
权限抽象
背景
小时光开发到现在,量级也算比较大了,回想这一年,做了很多搬砖的事情,比方说更改权限、添加广告位、增加记录类型等,每一次更改都倒腾一次。所以想能否将这些易变的事情抽象出来,对修改封闭,对扩展开放,客户端尽量能不发版实现需求。于是,就有了一系列的思考。这篇主要是关于如何将权限抽象出来,做到以后更改权限方面的需求,尽量能做到客户端不发版直接搞定,Server端不改代码或者少改代码搞定。
依赖倒转原则(Dependency Inversion Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。
能力/角色 | 创建者 | 管理员 | 亲友 | 粉丝 | ...... |
---|---|---|---|---|---|
看记录 | Y | Y | Y | Y | |
删除记录 | Y | N | N | N | |
小家改名 | Y | N | N | N | |
邀请成员 | Y | Y | Y | N | |
删除成员 | Y | Y | N | N | |
...... |
- 横向(角色)延伸
- 纵向(能力)延伸
客户端如何不发版,server端如何能够不改或者少改代码?
客户端
A. 增加一种角色 / 已有角色已有能力改变 (横向)
举例: 增加一种叫同事的角色
将目前的“通过角色确定权限”的方式,改为统一通过server端询问是否拥有能力。基本不需要知道角色这个概念。
拿“删除记录”按钮是否应该显示举例:
B. 增加一种能力 (纵向)
(1) 能力是已有的功能,但是一开始没有加权限判断
以“查看家庭成员列表”为例,原来有这个功能,任何人都可以进入这个页面,没有考虑权限的问题。
点击“小家列表”后,将走小家列表路由(5),底层捕捉到这个路由URL,由于是需要判断权限的路由,通过Server判断权限,如果没有权限,则返回上一页或者显示无权限页面。(2,3)
(2) 能力是没开发的功能(比如增加一个备注昵称的功能)
借助页面元素抽象化,以及RN,通过页面元素抽象可以动态增加一个入口,然后通过将页面的重要参数(4)传给RN,完成操作后RN可以调用本地页面方法,比如刷新页面(1)。
Server
设计到3张配置表的维护
- 角色表
- 能力表
- 角色/能力配置表
代码类似:
// 角色为“同事”能否查看“公开记录”
bool checkAccessWithRoleIDAndService:(4,“get_public_data”); // Y
无论“增加能力”还是“增加角色”都是维护着三张表。具体流程如下(以“能否查看评论”为例):