后台管理系统-1

后台管理系统模型设计

三种模型分析
1. 用户/权限模型
  1. 用户直接与权限映射，这种设计的优势在于简洁直观，适合用户数量不多，功能较为简单的系统，它的劣势也是非常的明显当用户量增多时，维护成本较高，可扩展性差。
  2. http://image.woshipm.com/wp-files/2020/07/mwyoS43tJcqgeRzfq4KT.png
2. 用户/角色/权限模型
  1. 若系统用户和功能增多，为每一个用户匹配单独的权限，会变得非常的繁琐，因此权限分门别类，形成“权限包”。从用户的角度，将用户分类，同一类用户固定为相同的角色，赋予相同的权限，会让操作变得简单很多。
  2. http://image.woshipm.com/wp-files/2020/07/xoagnjcKEvcYgSWvcmE2.png
3. 组织/用户/角色/权限模型
  1. 对于管理性后台，往往人员是职级区分的，比如用户王五为销售组长，其组员赵六和孙七，王五需要看到赵六和孙七的销售额数据和可以进行赵六和孙七的所有操作，而赵六仅能看到自己的销售额数据，进行和自己相关的操作。
    
    这个事例中引入了两个新的概念，一是用户的权限可以细分为功能权限和数据范围权限，二是数据范围和功能权限都有了继承的层级概念。
    
    所谓功能权限大家比较好理解，比如能否看到某个页面，能否点击某个按钮。而数据权限略抽象些，比如在业绩报表模块，从功能权限角度，可以决定用户能否打开这个报表页面，但是不同用户进来看到不同的数据（王五需要看到赵六和孙七的销售额数据，而赵六仅能看到自己的销售额数据，看不到孙七的），则是由数据范围来控制的。
  2. http://image.woshipm.com/wp-files/2020/07/UCaJN8g55WmVY045wmOe.png
  3. 1. 数据范围的继承
    
    我们可以将用户进行分级管理，比如建立多层级的组织架构树，将不同用户放置于组织架构的不同根节点上，来实现多层级用户的建立和管理。
    
    1）如果用户的层级如果比较简单（不多于三级），可以将层级关系融入到角色之中。比如用户分为三级：管理员-组长-组员，管理员能看到全部的数据范围和拥有全部的功能权限，而组长能查看组员的数据范围和拥有部分功能权限（比如无法编辑用户），而组员的数据范围仅仅为自己负责的数据和拥有部分功能权限。
    
    我们可以在组长这个角色下，允许其绑定组员，针对不同的角色设置不同的数据范围读取方式，管理员可以读取全部数据范围，组长需要读取其组员的，组员只能读取自己的。大家有兴趣可以去了解下RBAC0/1模型
    
    http://image.woshipm.com/wp-files/2020/07/DQWkbnDMUzUBPLGK1QaI.png
    
    2. 功能权限的继承
    
    涉及到组织架构树和角色树，需要考虑到的场景更多，这些细节要根据实际的业务场景来制定方案。比如：
    1. 组织有成立和解散的时间，员工也存在转岗换组织部门的情况，因此要考虑引入时间轴的概念。增加很多的校验逻辑，比如需要增加员工入职、离职时间，且员工在该部门任职的时间不能早于部门成立的时间等等
    2. 同一员工能否兼岗，允许在多个组织下存在
    3. 角色上是否会有互斥情况存在（RBAC-2模型），比如实际业务中，发钞和验钞的工作不允许同一个人做，因此在功能设计时要考虑角色之间的互斥性，通过为用户配置角色来实现用户与权限的映射关系，不同权限间是存在优先级的，比如刚刚的例子，互斥关系为最高优先级
    上述分析的三种权限管理其实并无优劣之分。权限管理作为系统的基石，应依据系统目标用户特点、后续发展方向、维护成本等方面进行综合评估，找到最适合系统的模式即可。
    
    知识点总结
    1. 用户管理核心是解决用户与权限的问题；
    2. 角色可理解为一类用户，或者一堆权限的集合，链接了用户与权限的关系；
    3. 权限可以分为功能权限和数据范围；
    4. 复杂的继承关系，数据范围依赖用户组织架构树，功能权限依赖角色树，将用户放置于组织架构树的不同节点上，并赋予角色，即解决了功能权限和数据范围的问题；
后台管理系统权限管理思路
1. 权限组放在前端
  1. 权限组放在前端：根据登录人不同选择不同的权限组。
2. 权限组全部由后端返回
  1. 权限全部由后端返回:你不管权限，你只要把后端返回的权限组按路由的规则遍历出来添加到Router里面就行了
3. 按钮权限：把按钮的名称放在一个数组里面，然后在按钮上使用v-if来判断有或者没有显示隐藏就行了。