.NET Core實戰項目之CMS 第七章 設計篇-用戶權限極簡設計全過程

寫在前面

這篇咱們對用戶權限進行極簡設計並保留其擴展性。首先很感謝你們的閱讀，前面六章我帶着你們快速入門了ASP.NET Core、ASP.NET Core的啓動過程源碼解析及配置文件的加載過程源碼解析並引入依賴注入的概念、Git的快速入門、Dapper的快速入門、Vue的快速入門。不知道大夥掌握的怎麼樣了！若是你有興趣的話能夠加入咱們的.NET Core實戰項目羣637326624跟更多的小夥伴共同進行交流下。

接下來咱們就正式進入.NET Core實戰項目之CMS的設計篇了。在設計篇呢，咱們須要對數據庫進行設計，而數據庫的設計又分爲功能部分設計以及用戶權限部分設計。做爲設計篇的第一篇，咱們先進行權限部分的設計吧！但願對你進行權限設計有所啓發。

本篇已經收錄至《.NET Core實戰項目之CMS 第一章 入門篇-開篇及整體規劃》

做者：依樂祝
原文地址：http://www.javashuo.com/article/p-aapozkkk-dn.html

需求分析

首先，作一個東西以前必須把需求搞清楚。網上關於權限管理需求分析以及設計的文章也比較多，這裏把咱們須要實現的這個簡單的CMS系統將要實現的權限部份內容羅列以下：

因爲水平有限，有設計不合理的地方還請給予指正，我會以迅雷不及掩耳之勢給以糾正，從而可以正確的引導更多的人。

1. 權限資源
   • 菜單權限：管理員跟內容編輯者登陸系統所擁有的功能菜單是不同的（先實現這塊）
   • 按鈕權限：管理員有文章審覈的功能，而內容編輯者沒有（文章審覈經過後才能進行發佈，最近聽羣裏小夥伴說權限控制如何控制到按鈕，這個後期會考慮加上）
   • 數據權限：內容編輯者A看不到內容編輯者B發表的文章，而管理員能夠看到A跟B的文章（這個後期也會考慮加上）

   • 字段權限：內容編輯者看不到文章的審批人是誰，而管理員能看到（這個後期也會考慮加上，並且脫離業務的字段權限，有點耍流氓的感受）

     目前權限部分初版只實現菜單權限部分，後期會擴展到按鈕權限，數據權限以及字段權限！由於若是設計的太多的話對不少新手朋友可能很難消化，同時若是設計的太多的話反而增長系統的複雜性，影響後面課程的進度。

2. 用戶
   用戶是應用系統的具體操做者，我這裏設計的是不能把權限直接分配給用戶，若是用戶想擁有某個權限，必須先爲這個用戶建立一個角色，而後給這個角色分配相應的權限，從而間接的讓用戶擁有了系統的權限（說的有點拗口，大夥將就着看吧）。固然國內的狀況是總有些人比較特殊，這時候能夠專門爲這我的建立一個特殊的角色來解決問題。

3. 角色
   爲了對許多擁有類似權限的用戶進行分類管理，定義了角色的概念，以上全部的權限資源均可以分配給角色，而後經過給用戶分配某個角色，從而達到給用戶分分配目的（就是爲了解耦資源權限和用戶）角色和用戶是N:N的關係。

設計

通過N次優化的數據庫結構設計。原本數據庫核心表中有不少多對多的關係（用戶與角色/角色與菜單等），因此中間多了不少關聯關係表，後來想一想以爲何苦呢，爲何大夥都喜歡這樣的設計，因此爲了簡化這個過程我進行了以下的設計：

這裏你可能會問我：全部多對多的關係都放在一張表裏面，怎麼保證性能呢？什麼？性能？沒有千萬級別的數據，別跟我談性能。若是你的系統幾十萬數據時都會很卡的話，仍是乖乖的去惡補一下數據庫基礎吧。

數據庫設計我採用的是PowerDesigner,首先打開軟件，新建一個概念模型。而後對這塊的設計以下：

上圖可能不清晰，因此下面我會對每一個表進行詳細的說明。

表詳細說明

後臺管理員

後臺管理員顧名思義就是對咱們的後臺進行管理的人。這裏考慮到後期擴展可能會用到會員系統（Users）所以這裏的後臺管理員表名使用Manager 。後臺管理員包含的信息有：
主要信息：主鍵，角色ID，是否鎖定
登陸相關信息：用戶名，密碼
個性化信息：暱稱，頭像
聯繫方式信息：手機號碼，郵箱地址
登陸相關信息：登陸次數，最後一次登陸IP,最後一次登陸時間
操做相關信息：添加人，添加時間，修改人，修改時間
其餘信息：是否刪除，備註

後臺管理員角色

這裏爲了使後臺管理員與後臺菜單進行解耦引入了角色的概念。一個後臺管理員想要具備某個菜單的功能必須給它分配相應角色才能能夠，角色又分爲系統管理員和超級管理員。超級管理員的角色不能進行修改，擁有後臺的全部權限。而系統管理員的功能則能夠進行個性化的定製來知足需求。

主要信息：主鍵，角色類型（超級管理員以及系統管理員），角色名稱，是否系統默認（系統默認不能刪除，防止誤刪除）
操做相關信息：添加人，添加時間，修改人，修改時間
其餘 信息：是否刪除，備註

後臺管理菜單

後臺管理菜單是後臺的功能導航。是具體功能的單位，固然每一個後臺管理菜單還包含相應的操做權限，這塊咱們後期再作具體操做的設計，前期爲了考慮大部分人因此這裏暫不考慮，可是我已經預留了字段，聰明如你，應該猜獲得這是哪一個字段吧！
主要信息：主鍵，父菜單ID
個性化信息：名稱，顯示名稱，圖標地址，連接地址，排序字段，操做權限（沒錯，保留字段，爲後期操做權限作準備）
操做信息：添加人，添加時間，修改人，修改時間
其餘信息：是否刪除

角色權限表

用來設計角色權限，因爲目前只有菜單權限，後期能夠在此表進行操做權限，以及其餘權限的擴展：
主要信息：主鍵，角色ID，菜單ID
其餘信息：操做類型

操做日誌

顧名思義，就是對後臺管理員的各類操做進行簡要的記錄
主要信息：主鍵，操做類型
操做信息：操做人，操做時間，操做IP，操做人名稱
其餘信息：備註

GitHub地址

這裏我會把權限設計以及內容管理設計的邏輯視圖上傳到GayHub上，這裏給出地址。以爲不錯的，能夠給個Star!後續咱們也會在這個GayHub倉庫進行開發的！

GitHub：https://github.com/yilezhu/Czar.Cms
碼雲：https://gitee.com/yilezhu/Czar.Cms

總結

今天帶着你們進行用戶權限模塊的設計，經過再三的斟酌只保留了這五張表，因此保留下來的這五張表也都個個是精華。以前設計的時候想不通爲何那麼熱衷於那麼多的多對多設計，這樣的極簡設計也別有一番風味，瞬間感受整個世界都簡單了不少。若是又以爲個人設計不合理的話，還請你們在下面留言或者加我聯繫我吧！寫文章須要動力，但願你們給個推薦支持一下哈！