前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >.NET Core实战项目之CMS 第七章 设计篇-用户权限极简设计全过程

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

作者头像
依乐祝
发布2018-12-06 10:26:59
7950
发布2018-12-06 10:26:59
举报
文章被收录于专栏:依乐祝依乐祝依乐祝

写在前面

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

需求分析

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

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

  1. 权限资源
    • 菜单权限:管理员跟内容编辑者登录系统所拥有的功能菜单是不一样的(先实现这块)
    • 按钮权限:管理员有文章审核的功能,而内容编辑者没有(文章审核通过后才能进行发布,最近听群里小伙伴说权限控制如何控制到按钮,这个后期会考虑加上)
    • 数据权限:内容编辑者A看不到内容编辑者B发表的文章,而管理员可以看到A跟B的文章(这个后期也会考虑加上)
    • 字段权限:内容编辑者看不到文章的审批人是谁,而管理员能看到(这个后期也会考虑加上,而且脱离业务的字段权限,有点耍流氓的感觉) 目前权限部分第一版只实现菜单权限部分,后期会扩展到按钮权限,数据权限以及字段权限!因为如果设计的太多的话对很多新手朋友可能很难消化,同时如果设计的太多的话反而增加系统的复杂性,影响后面课程的进度。
  2. 用户 用户是应用系统的具体操作者,我这里设计的是不能把权限直接分配给用户,如果用户想拥有某个权限,必须先为这个用户创建一个角色,然后给这个角色分配相应的权限,从而间接的让用户拥有了系统的权限(说的有点拗口,大伙将就着看吧)。当然国内的情况是总有些人比较特殊,这时候可以专门为这个人创建一个特殊的角色来解决问题。
  3. 角色 为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,以上所有的权限资源都可以分配给角色,然后通过给用户分配某个角色,从而达到给用户分分配目的(就是为了解耦资源权限和用户)角色和用户是N:N的关系。

设计

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

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

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

1543760443427
1543760443427

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

表详细说明

后台管理员

1543762193709
1543762193709

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

后台管理员角色

1543762177148
1543762177148

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

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

后台管理菜单

1543762149541
1543762149541

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

角色权限表

1543762126759
1543762126759

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

操作日志

1543762102050
1543762102050

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

总结

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018-12-02 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 写在前面
  • 需求分析
  • 设计
  • 表详细说明
    • 后台管理员
      • 后台管理员角色
        • 后台管理菜单
          • 角色权限表
            • 操作日志
            • 总结
            相关产品与服务
            数据库
            云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档