前言：“我們有一個訂單列表，希望能夠根據當前登陸的不同使用者看到不同型別的訂單資料”、“我們希望不同的使用者能看到不同時間段的掃描報表資料”、“我們系統需要不同使用者檢視不同的生產報表列”。諸如此類，最近經常收到專案上面的客戶提出的這種問題，即所謂的“資料許可權”，經過開會討論決定：在目前的開發框架上面搭建一套通用的資料許可權功能。

一、大話許可權模組

有了上面的引言，自然而然就引出了今天需要和大家討論的話題——資料許可權。作為開發人員，我們肯定知道，一般的系統都離不開許可權模組，它是支撐整個系統執行的基礎模組。而根據專案型別和需求的不同，許可權模組的設計更是大相徑庭。但不管怎麼變，許可權模組從大的方面來說，可以分為兩種大的型別：功能許可權

• 功能許可權：主要控制不同的資源主體（使用者、角色、組織等）有操作不同的資源的許可權。比如常見的不同的角色能訪問不同的頁面（選單許可權），以及具有操作同一頁面的不同功能（按鈕許可權）等等，都資料功能許可權的範疇，這種設計相對比較簡單，也比較為大多數系統所通用。當然網上資料、設計思路也可以找到很多。
• 資料許可權：主要控制不同的資源主體（使用者、角色、組織等）有檢視不同的資料資訊的許可權，一般來說，資料許可權又分為資料行許可權和資料列許可權，通過字面意思不難理解這兩者的區別，比如上文“我們有一個訂單列表，希望能夠根據當前登陸的不同使用者看到不同型別的訂單資料” 這就是一個典型的資料行許可權，而“我們系統需要不同使用者檢視不同的生產報表列”這就是資料列許可權的範疇。由於資料許可權和系統的業務邏輯關係非常密切，所以不同的系統設計差異性會非常大。從另一方面來說，由於資料許可權和業務邏輯關聯性非常強，如果系統的業務邏輯非常複雜，資料許可權設計起來也會相對複雜，所以關於資料許可權的設計一直沒有一種相對通用和使用簡單的設計方案。

如果你動手去設計資料許可權，當你去各大平臺、百度、谷歌查詢設計思路的時候，你會發現很難找到有用的資料，很多設計思路侷限性非常大。其實原因很簡單：資料許可權的設計和他人系統關係緊密，一般不太容易拿到你的專案上面直接使用。

當然也有另外部分人說“資料許可權並不能作為許可權模組去設計”，比如博主看到這樣一條評論

從一定程度上來說，這樣理解也不為過，如果你覺得你的系統靈活性和配置性不需要那麼高，把資料許可權的規則在程式碼裡面寫死又何妨，博主所在公司的另外一個部門就是這麼幹的，除了編碼量大一點，其實也沒什麼太大的問題！其實博主說這麼多無非是想表達一個觀點：沒有絕對通用的資料許可權設計思路，關鍵看合不合你用！當然本文的設計思路也是一樣，不強制要求，不提通用。設計思路供你參考！

二、一種設計思路

關於許可權設計的雜談就告一段落，凡是點到即止，再說了多了就說爛了。到目前為止，博主找到的一篇寫得相對比較好的文章 通用許可權管理設計 之 資料許可權。這位博主是用sql去實現的，如果是把這個運用到EF裡面的話，考慮到EF複雜的導航屬性，會有一些問題。接下來說說博主這邊想到的設計思路。

先說說博主所在專案的情況，和資料打交道的部分採用EntityFramework+Repository的傳統模式去實現的，整個專案從上到下，就是一種典型的"偽DDD"，什麼是”偽DDD“？這裡不做過多說明，使用過DDD的同仁應該很清楚。下面是設計思路流程圖：

第一步：配置資料規則

第二步：頁面使用資料規則

 以上是一個大致的思路圖，總的來說，要實現基於EF的資料許可權設計，主要分為兩大步驟

1、配置資料規則

配置資料規則這裡有三個大的方面：功能模組、資料資源、角色

• 功能模組：為什麼這裡要加上功能模組的約束？是因為博主覺得我們某一個頁面在查詢資料的時候，會有一個查詢的範圍，比如訂單查詢頁面肯定只能查詢和訂單有關聯的實體功能，而不可能查詢和它沒有任何關聯的業務。加這個約束更大的意義在於我們動態的構造Lambda去查詢實體的時候不會產生”找不到相關聯的實體“之類的錯誤。
• 資料資源：具體對哪種資料資源做資料許可權，比如訂單的狀態不等於取消狀態、訂單的下單時間小於當前月份等等。
• 角色：資料資源的主體，還可以是使用者、部門、組織等等。

這三者配置之後得到的一個結果就是某一類角色的某一個功能模組對哪個資料資源的資料規則是什麼樣的。比如有一條銷售總監的資料規則，配置銷售總監在訂單模組裡面訂單這個實體的訂單型別是銷售訂單的所有資料，這就是針對銷售總監在訂單模組的資料規則。可能最終資料庫儲存得到的資料類似這樣：

需要特別說明的是：由於EF有導航屬性，這裡的Rules在儲存的時候如果遇到導航屬性，我們的欄位值需要這樣儲存——Product.Categary.Type。因為在我們轉換成為lambda表示式的時候導航屬性會是這樣寫：x=>x.Product.Categary.Type==1。這個我們在後面使用這個規則的時候加以說明。

2、使用資料規則

 有了上面的資料規則，接下來就是我們在取資料的時候如何使用了，這裡有一點需要說明的是：我們這裡需要傳兩個引數，一個是模組的名稱，比如上面的OrderQuery、Product等；第二個是當前使用者的角色id，這個可以通過當前登陸使用者的id獲取到角色。

要使用資料規則，之前博主分享過兩篇關於動態Lambda的文章，現在派上用場了。只不過原來只是一些基礎型別轉lambda，現在涉及到了導航屬性，不知道是否可行。博主查閱了一些資料，最終找到了解決方案。

　　　　 //遍歷得到屬性（包括遍歷導航屬性）
        public Expression GetProperty(Expression source, ParameterExpression para, string Name)
        {
            string[] propertys = Name.Split('.');
            if (source == null)
            {
                source = Expression.Property(para, typeof(Entity).GetProperty(propertys.First()));
            }
            else
            {
                source = Expression.Property(source, propertys.First());
            }
            foreach (var item in propertys.Skip(1))
            {
                source = GetProperty(source, para, item);
            }
            return source;
        }

然後測試如下

　　　　　　　　　　　　var oLamadaExtention = new LambdaExpression<Order>();
                    var left = oLamadaExtention.GetProperty(null, Expression.Parameter(typeof(Order), "x"), "Product.Categary.Type");
                    var value = Expression.Constant("1", left.Type);
                    //動態轉換型別
                    var right = Expression.Constant(value, left.Type);
                    Expression expRes = Expression.Equal(left, right);

測試得到的查詢lambda結果為x=>x.Product.Categary.Type=="1"，測試成功！

3、補充一點

對於配置資料規則的時候還有一點比較麻煩的是，如果如何知道哪個功能模組使用哪些實體？不可能直接讓使用者去寫Product.Categary.Type這些複雜的功能吧，如果是這樣，談何體驗。那麼只有使用另外一種解決思路了——反射EF實體。

反射EF實體的時候如果是導航屬性，還得繼續反射導航屬性的實體，這樣一層一層反射下去，最終確實是可以得到形如Product.Categary.Type這個的結構體，但介面如何展現還有待思考。比如思路如下：

三、總結

以上只是一個設計思路，理論上來說是可以實現的，如有不足，歡迎斧正，謝謝。如果思路沒有問題，後續博主會抽時間將這種設計的實現過程展現出來供大家參考，歡迎關注。其中的難點有兩個：

1、逐級反射EF的導航屬性，以及這個過程如何展現。是通過特性標記，還是開發人員配置；

2、動態Expression在構造Lambda的時候和配置資料的相容性問題，比如資料型別的相容性有點難控制。

歡迎各位轉載，但是未經作者本人同意，轉載文章之後必須在文章頁面明顯位置給出作者和原文連線，否則保留追究法律責任的權利