权限抽象

权限抽象

背景

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

不管“增长能力”仍是“增长角色”都是维护着三张表。具体流程以下（以“可否查看评论”为例）：