.NET Core实战项目之CMS 第七章 设计篇-用户权限极简设计全过程

写在前面

这篇我们对用户权限进行极简设计并保留其扩展性。首先很感谢大家的阅读，前面六章我带着大家快速入门了asp.net core、asp.net core的启动过程源码解析及配置文件的加载过程源码解析并引入依赖注入的概念、git的快速入门、dapper的快速入门、vue的快速入门。不知道大伙掌握的怎么样了！如果你有兴趣的话可以加入我们的.net core实战项目群637326624跟更多的小伙伴共同进行交流下。

接下来我们就正式进入.net core实战项目之cms的设计篇了。在设计篇呢，我们需要对数据库进行设计，而数据库的设计又分为功能部分设计以及用户权限部分设计。作为设计篇的第一篇，我们先进行权限部分的设计吧！希望对你进行权限设计有所启发。

本篇已经收录至《.net core实战项目之cms 第一章 入门篇-开篇及总体规划》

作者：依乐祝
原文地址：

需求分析

首先，做一个东西之前必须把需求搞清楚。网上关于权限管理需求分析以及设计的文章也比较多，这里把我们需要实现的这个简单的cms系统将要实现的权限部分内容罗列如下：

由于水平有限，有设计不合理的地方还请给予指正，我会以迅雷不及掩耳之势给以纠正，从而能够正确的引导更多的人。

1. 权限资源
   • 菜单权限：管理员跟内容编辑者登录系统所拥有的功能菜单是不一样的（先实现这块）
   • 按钮权限：管理员有文章审核的功能，而内容编辑者没有（文章审核通过后才能进行发布，最近听群里小伙伴说权限控制如何控制到按钮，这个后期会考虑加上）
   • 数据权限：内容编辑者a看不到内容编辑者b发表的文章，而管理员可以看到a跟b的文章（这个后期也会考虑加上）

   • 字段权限：内容编辑者看不到文章的审批人是谁，而管理员能看到（这个后期也会考虑加上，而且脱离业务的字段权限，有点耍流氓的感觉）

     目前权限部分第一版只实现菜单权限部分，后期会扩展到按钮权限，数据权限以及字段权限！因为如果设计的太多的话对很多新手朋友可能很难消化，同时如果设计的太多的话反而增加系统的复杂性，影响后面课程的进度。

2. 用户
   用户是应用系统的具体操作者，我这里设计的是不能把权限直接分配给用户，如果用户想拥有某个权限，必须先为这个用户创建一个角色，然后给这个角色分配相应的权限，从而间接的让用户拥有了系统的权限（说的有点拗口，大伙将就着看吧）。当然国内的情况是总有些人比较特殊，这时候可以专门为这个人创建一个特殊的角色来解决问题。

3. 角色
   为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，以上所有的权限资源都可以分配给角色，然后通过给用户分配某个角色，从而达到给用户分分配目的（就是为了解耦资源权限和用户）角色和用户是n:n的关系。

设计

经过n次优化的数据库结构设计。本来数据库核心表中有很多多对多的关系（用户与角色/角色与菜单等），所以中间多了很多关联关系表，后来想想觉得何苦呢，为什么大伙都喜欢这样的设计，所以为了简化这个过程我进行了如下的设计：

这里你可能会问我：所有多对多的关系都放在一张表里面，怎么保证性能呢？什么？性能？没有千万级别的数据，别跟我谈性能。如果你的系统几十万数据时都会很卡的话，还是乖乖的去恶补一下数据库基础吧。

数据库设计我采用的是powerdesigner,首先打开软件，新建一个概念模型。然后对这块的设计如下：

上图可能不清晰，所以下面我会对每个表进行详细的说明。

表详细说明

后台管理员

后台管理员顾名思义就是对我们的后台进行管理的人。这里考虑到后期扩展可能会用到会员系统（users）因此这里的后台管理员表名使用manager 。后台管理员包含的信息有：
主要信息：主键，角色id，是否锁定
登录相关信息：用户名，密码
个性化信息：昵称，头像
联系方式信息：手机号码，邮箱地址
登录相关信息：登录次数，最后一次登录ip,最后一次登录时间
操作相关信息：添加人，添加时间，修改人，修改时间
其他信息：是否删除，备注

后台管理员角色

这里为了使后台管理员与后台菜单进行解耦引入了角色的概念。一个后台管理员想要具有某个菜单的功能必须给它分配相应角色才能可以，角色又分为系统管理员和超级管理员。超级管理员的角色不能进行修改，拥有后台的所有权限。而系统管理员的功能则可以进行个性化的定制来满足需求。

主要信息：主键，角色类型（超级管理员以及系统管理员），角色名称，是否系统默认（系统默认不能删除，防止误删除）
操作相关信息：添加人，添加时间，修改人，修改时间
其他 信息：是否删除，备注

后台管理菜单

后台管理菜单是后台的功能导航。是具体功能的单位，当然每个后台管理菜单还包含相应的操作权限，这块我们后期再做具体操作的设计，前期为了考虑大部分人所以这里暂不考虑，但是我已经预留了字段，聪明如你，应该猜得到这是哪个字段吧！
主要信息：主键，父菜单id
个性化信息：名称，显示名称，图标地址，链接地址，排序字段，操作权限（没错，保留字段，为后期操作权限做准备）
操作信息：添加人，添加时间，修改人，修改时间
其他信息：是否删除

角色权限表

用来设计角色权限，由于目前只有菜单权限，后期可以在此表进行操作权限，以及其他权限的扩展：
主要信息：主键，角色id，菜单id
其他信息：操作类型

操作日志

顾名思义，就是对后台管理员的各种操作进行简要的记录
主要信息：主键，操作类型
操作信息：操作人，操作时间，操作ip，操作人名称
其他信息：备注

总结

今天带着大家进行用户权限模块的设计，通过再三的斟酌只保留了这五张表，所以保留下来的这五张表也都个个是精华。之前设计的时候想不通为什么那么热衷于那么多的多对多设计，这样的极简设计也别有一番风味，瞬间感觉整个世界都简单了很多。如果又觉得我的设计不合理的话，还请大家在下面留言或者加我联系我吧！写文章需要动力，希望大家给个推荐支持一下哈！