先後端分離開發中動態菜單的兩種實現方案

時間 2019-11-06

標籤後端分離開發動態菜單兩種實現方案简体版

原文原文鏈接

關於先後端分離開發中的權限處理問題，鬆哥以前寫過一篇文章和你們聊這個問題：前端

Spring Boot + Vue 先後端分離開發，權限管理的一點思路

可是最近有小夥伴在學習微人事項目時，對動態菜單這一塊仍是有疑問（即不一樣用戶登陸成功後會看到不一樣的菜單項），所以鬆哥打算再來寫一篇文章和你們聊一聊先後端分離開發中的動態菜單問題。vue

1. 一個原則

作權限管理，一個核心思想就是後端作權限控制，前端作的全部工做都只是爲了提升用戶體驗，咱們不能依靠前端展現或者隱藏一個按鈕來實現權限控制，這樣確定是不安全的。git

就像用戶註冊時須要輸入郵箱地址，前端校驗以後，後端仍是要校驗，兩個校驗目的不一樣，前端校驗是爲了提升響應速度，優化用戶體驗，後端校驗則是爲了確保數據完整性。權限管理也是如此，前端按鈕的展現/隱藏都只是爲了提升用戶體驗，真正的權限管理須要後端來實現。github

這是很是重要的一點，作先後端分離開發中的權限管理，咱們首先要創建上面這樣的思考框架，而後在這樣的框架下，去考慮其餘問題。json

所以，下文我會和你們分享兩種方式實現動態菜單，這兩種方式僅僅只是探討如何更好的給用戶展現菜單，而不是探討權限管理，由於權限管理是在後端完成的，也必須在後端完成。後端

2. 具體實現

一旦創建起這樣的思考框架，你會發現動態菜單的實現辦法太多了。數組

動態菜單就是用戶登陸以後看到的菜單，不用角色的用戶登陸成功以後，會看到不用的菜單項，這個動態菜單要怎麼實現呢？總體來講，有兩種不一樣的方案，鬆哥曾經作過的項目中，兩種方案也都有用過，這裏分別來和你們分享一下。安全

2.1 後端動態返回

後端動態返回，這是我在微人事中採用的方案。微人事中，權限管理相關的表一共有五張表，以下：框架

其中 hr 表就是用戶表，用戶登陸成功以後，能夠查詢到用戶的角色，再根據用戶角色去查詢出來用戶能夠操做的菜單（資源），而後把這些能夠操做的資源，組織成一個 JSON 數據，返回給前端，前端再根據這個 JSON 渲染出相應的菜單。以微人事爲例，咱們返回的 JSON 數據格式以下：前後端分離

[
    {
        "id":2,
        "path":"/home",
        "component":"Home",
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":"EmpBasic",
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]
複製代碼

這樣的 JSON 在前端中再進行二次處理以後，就可使用了，前端的二次處理主要是把 component 屬性的字符串值轉爲對象。這一塊具體操做你們能夠參考微人事項目（具體在：https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js），我就再也不贅述了。

這種方式的一個好處是前端的判斷邏輯少一些，後端也不算複雜，就是一個 SQL 操做，前端拿到後端的返回的菜單數據，稍微處理一下就能夠直接使用了。另外這種方式還有一個優點就是能夠動態配置資源-角色以及用戶-角色之間的關係，進而調整用戶能夠操做的資源(菜單)。

2.2 前端動態渲染

另外一種方式就是前端動態渲染，這種方式後端的工做要輕鬆一些，前端處理起來麻煩一些，鬆哥去年年底幫一個律所作的一個管理系統，由於權限上比較容易，我就採用了這種方案。

這種方式就是我直接在前端把全部頁面都在路由表裏邊定義好，而後在 meta 屬性中定義每個頁面須要哪些角色才能訪問，例以下面這樣：

[
    {
        "id":2,
        "path":"/home",
        "component":Home,
        "name":"員工資料",
        "iconCls":"fa fa-user-circle-o",
        "children":[
            {
                "id":null,
                "path":"/emp/basic",
                "component":EmpBasic,
                "name":"基本資料",
                "iconCls":null,
                "children":[

                ],
                "meta":{
                    "keepAlive":false,
                    "requireAuth":true,
                    "roles":['admin','user']
                }
            }
        ],
        "meta":{
            "keepAlive":false,
            "requireAuth":true
        }
    }
]
複製代碼

這樣定義表示當前登陸用戶須要具有 admin 或者 user 角色，才能夠訪問 EmpBasic 組件，固然這裏不是說我這樣定義了就行，這個定義只是一個標記，在項目首頁中，我會遍歷這個數組作菜單動態渲染，而後根據當前登陸用戶的角色，再結合當前組件須要的角色，來決定是否把當前組件所對應的菜單項渲染出來。

這樣的話，後端只須要在登陸成功後返回當前用戶的角色就能夠了，剩下的事情則交給前端來作。不過這種方式有一個弊端就是菜單和角色的關係在前端代碼中寫死了，之後若是想要動態調整會有一些不方便，可能須要改代碼。特別是大項目，權限比較複雜的時候，調整就更麻煩了，因此這種方式我通常建議在一些簡單的項目中使用。