前言
之前公司让开发了一款小产品，采取前后端分离的方式。在选取技术时，决定使用了aspnetcore 开发api端，使用angular开发了后台管理页面，使用mpvue开发了小程序。抱着一边学一边做的心态来开发的这个项目，于是在开发过程中，总结的一些东西汇总了一下整理到了自己的github中，形成了这个小系统。主要的目的是学习，方案必定也是不成熟的，希望以后有时间能不断扩充它的功能。
总之先上地址：https://github.com/aishang2015/Yu
整体分析
系统扩展了asp net core identiy的功能。identity是什么呢，简而言之就是微软的一套身份认证系统。这套系统给我们提供了一套数据库模板和操作该系统的方法集，我们可以直接使用也可以对它进行扩展。
identity的数据库模板是这样的，先从数据角度分析一下。
下边一个一个来看：
- 最重要的AspNetUsers，顾名思义是用户的信息表。
- AspNetRoles，这个表里记录系统的所有角色。
- AspNetUserRoles，当然就是用户和角色的关联表了。
- AspNetUserClaims和AspNetRoleClaims，就是记录用户或角色相关的Claims。Claim的代码在这里。实际上它就是记录用户身份信息的一种数据结构，包含ClaimType，ClaimValue，就好像元组一样的数据结构。所以这两个表就是记录关联到用户或者角色上的一些信息。
下边来看看想要实现的功能：
- 菜单的权限，就是可以控制用户能看否到某些菜单。
- 页面元素的权限，就是页面上的按钮，链接或是表格列之类的一些东西，可以控制是否让用户使用。
- 配置用户所属的部门组织
- 配置数据规则，让特定用户按照某些固定的规则去访问数据。举个例子：某个角色譬如管理人员A能看到所有销售数据，管理人员B只能看到自己部门的销售数据，业务人员A只能看到自己的销售数据。
再来看一看怎么和AspNetUsers和AspNetRoles进行关联：
- 菜单和元素应该是和角色相关的权限，通过给用户分配角色就会把菜单和元素的权限配置到用户。所以应该把信息放到AspNetRoleClaims内，就完成了角色和菜单元素的关联。
- 部门组织应该是和用户直接相关的内容。所以信息应该放到AspNetUserClaims内。
- 数据规则也应该是通过角色赋予给用户的。所以角色和规则的关联应该记录到AspNetRoleClaims内。
通过上边可以看出无论我们想要任何类型的权限，和角色相关的只需要记录到AspNetRoleClaims内，和具体用户相关的权限只需要记录到AspNetUserClaims。只需要我们定义好自己的ClaimType，然后把权限相关的内容记录到ClaimValue就可以了。
关于菜单和元素
因为是前后端分离项目，所以把前端的菜单内容静态化到代码内。也就是说菜单的内容修改需要对前端代码进行代码修改。这样一来，可以看到实际上菜单和普通的页面元素就没有什么区别了。所以就可以整合到一个表了。
元素的数据定义是这样的
- BaseEntity：所有实体的基类定义了Id为默认主键。
- Element：记录所有页面元素。
- ElementTree:记录所有元素的父子关系。是这样的，一个菜单下有可能有几个菜单，这些菜单对应的页面中有可能有多个元素，所以用这个表来记录所有的元素的关系。
- Api：记录Api端所有的api的信息。
- ElementApi：记录页面元素关联的api信息。
先看Element，ElementType定义了元素的类型，菜单或是链接或是按钮等。Identification字段定义了页面元素的唯一识别，前端页面也就是通过这个字段来判断是否显示元素。Route字段针对有路由变化的页面元素，例如菜单等，他记录了该元素可访问的路由。
为什么关联api呢，因为无论是Identification或者是Route字段只能保证用户不通过页面访问api，都无法组织用户拿着token直接访问api。所以api和element进行关联，保证用户只能访问对应元素的api。
最后一个问题，页面元素和角色进行关联。这时只需要定义好我们的ClaimType，然后把Element的Id设为ClaimValue。然后将数据保存到AspNetRoleClaims内即完成了。
关于组织
组织的数据元素就简单了
- Group：组织信息。
- GroupTree:记录组织上下级关系。
组织和用户进行关联，定义好我们的ClaimType，然后把Group的Id设为ClaimValue。然后将数据保存到AspNetUserClaims即完成用户和组织的关联。
先写到这里，下篇说一说数据权限的定义。