权限抽象

权限抽象

背景

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

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

转载于:https://www.cnblogs.com/zhang-chi/p/8365695.html