前言
之前公司讓開發了一款小產品，採取前後端分離的方式。在選取技術時，決定使用了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即完成用戶和組織的關聯。
先寫到這裏，下篇說一說數據權限的定義。