权限抽象

权限抽象

背景

小时光开发到现在,量级也算比较大了,回想这一年,做了很多搬砖的事情,比方说更改权限、添加广告位、增加记录类型等,每一次更改都倒腾一次。所以想能否将这些易变的事情抽象出来,对修改封闭,对扩展开放,客户端尽量能不发版实现需求。于是,就有了一系列的思考。这篇主要是关于如何将权限抽象出来,做到以后更改权限方面的需求,尽量能做到客户端不发版直接搞定,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张配置表的维护

  1. 角色表

  1. 能力表

  1. 角色/能力配置表

代码类似:

// 角色为“同事”能否查看“公开记录”
bool checkAccessWithRoleIDAndService:(4,“get_public_data”); // Y

无论“增加能力”还是“增加角色”都是维护着三张表。具体流程如下(以“能否查看评论”为例):

posted @ 2018-01-27 13:50  张驰小方块  阅读(277)  评论(0编辑  收藏  举报