APP開發 軟件開發 APP開發公司 軟件開發公司

    1、數據權限概述
    1.1、什(shén)麽是數據權限？
    數據權限是指對(duì)系統用(yòng)戶對(duì)數據資源可(kě)見性的(de)控制。流行的(de)解釋是，滿足某種條件的(de)用(yòng)戶隻能在該條件下(xià)看到相應的(de)數據資源。所以最簡單的(de)數據權限可(kě)能是：用(yòng)戶隻能看到自己的(de)數據。在正式的(de)系統環境中，有許多(duō)更複雜(zá)的(de)數據權限需求方案，例如：
    領導需要看到所有下(xià)屬員(yuán)工的(de)客戶數據，員(yuán)工隻能看到自己的(de)客戶數據；
    經理(lǐ)A可(kě)以看到所有企業客戶，B經理(lǐ)隻能看到企業客戶年銷售額不到1000萬；
    a角色可(kě)以看到全國的(de)産品數據，B角色隻能看到上海的(de)産品數據；
    這(zhè)些要求也(yě)可(kě)以通(tōng)過使用(yòng)硬編碼實現，但是在業務的(de)快(kuài)速發展過程中，對(duì)于類似的(de)數據權限将有越來(lái)越多(duō)的(de)要求。如果所有這(zhè)些要求都是硬編碼的(de)，它無疑将給我們帶來(lái)巨大(dà)的(de)發展和(hé)維護壓力。
    1.2、要素分(fēn)析
    從當前登錄用(yòng)戶的(de)角度來(lái)看，數據權限的(de)定義可(kě)以理(lǐ)解爲：當前登錄用(yòng)戶隻能看到用(yòng)戶權限範圍内的(de)數據資源。由此，可(kě)以分(fēn)析數據權限控制的(de)幾個(gè)關鍵要素：
    主體，即當前登錄用(yòng)戶。領導和(hé)角色等概念可(kě)以轉換爲當前登錄用(yòng)戶是否是領導者，以及他(tā)或她是否具有角色。
    數據資源。即受控系統數據。
    有條件的(de)規則。也(yě)就是說，當前登錄用(yòng)戶對(duì)于特定的(de)數據資源适用(yòng)的(de)條件。
    2、數據權限設計
    理(lǐ)論上，當用(yòng)戶訪問被控制的(de)系統數據時(shí)，可(kě)以得(de)到用(yòng)戶應用(yòng)于數據資源的(de)條件規則，并将條件規則解析爲SQL查詢語句，實現對(duì)數據的(de)權限控制。但是，在實現中仍然存在許多(duō)困難，例如以下(xià)規則适用(yòng)于當前登錄用(yòng)戶：
    客戶數據：[客戶經理(lǐ)][包含在][下(xià)屬人(rén)員(yuán)]産品數據：[銷售地區(qū)][等于][上海]訂單數據：（[産品銷售地區(qū)][等于][上海]）[和(hé)]（[客戶營銷經理(lǐ)][包含在][下(xià)屬人(rén)員(yuán)]）
    思考如下(xià)問題：
    [accountManager][included][submiters]如何解析爲SQL語句？如何處理(lǐ)多(duō)表聯合查詢？
    下(xià)屬由系統根據當前的(de)登錄用(yòng)戶進行計算(suàn)，上海則根據管理(lǐ)員(yuán)的(de)背景進行選擇。這(zhè)兩種方法如何兼容？
    如何設計複雜(zá)多(duō)變的(de)組合條件？
    如何确定應用(yòng)于當前查詢的(de)條件？
    一個(gè)用(yòng)戶應該如何具有多(duō)個(gè)角色，不同角色應該如何爲同一規則設置不同的(de)值？
    2.1、規則元
    名詞定義：正則元素。在本文中，它是指一個(gè)獨立的(de)數據規則定義。不同的(de)用(yòng)戶可(kě)以爲規則元素設置特定的(de)規則篩選值，作爲數據查詢的(de)篩選條件。在上述規則中，[客戶經理(lǐ)]和(hé)[銷售地區(qū)]屬于規則元素。
    2.2、規則元配置
    一。規則元名稱的(de)配置。表中的(de)哪些字段可(kě)以由規則設置，以及規則元名稱如何與表字段相關聯。（例如，在上面的(de)規則[客戶經理(lǐ)]，[銷售區(qū)域]）中，很容易想到通(tōng)過配置文件來(lái)維護規則名和(hé)數據庫字段之間的(de)關系。
    2.規則元素值數據源的(de)配置。例如，【下(xià)屬人(rén)員(yuán)】和(hé)【上海】在上述規則中，不難發現規則人(rén)民币價值有三個(gè)來(lái)源：
    後台管理(lǐ)人(rén)員(yuán)輸入。
    系統提供數據源，後台管理(lǐ)器選擇。例如：地點[上海]
    系統提供數據。如：[下(xià)屬人(rén)員(yuán)]
    配置文件可(kě)以滿足數據規則的(de)配置要求，但是當規則元素越來(lái)越多(duō)，維護配置文件變得(de)很麻煩，我們可(kě)以遵循Spring-boot而不是Spring-MVC的(de)實踐，而是使用(yòng)注釋而不是配置？每一條數據規則最終都會落入數據庫字段的(de)控制之中，現在大(dà)多(duō)數系統都會有一個(gè)對(duì)應于數據庫中表的(de)模型層，所以brain組成了(le)一個(gè)完美(měi)的(de)規則元配置模式：
    @TableName（“test“）
    Public class TestModal extension abstract model {\ expndtw-1
    @數據規則（name=“rule meta name”）
    Private string name;
    }
    @DataRule注解源碼如下(xià)：
    @Target（{ElementType.FIELD}）
    @Retention (retention policy.(runtime)
    public @interface DataRule {
    /**
    * 規則元名稱
    */
    String name() default ";
    /**
    * 規則元值來(lái)源類型
    */
    RuleSourceStrategy () default RuleSourceStrategy.Text;
    /**
    *當用(yòng)戶選擇數據源時(shí){@code rulesourcestrategyChoice}數據地址
    */
    The string URL () defaults to "";
    /**
    *當數據源由系統提供時(shí){@code rulesourcestrategySystem}提供程序類名稱
    */
    Class provider（） default NullDataRuleProvider.Class;
    }
    啓動系統時(shí)，規則元素配置信息（名稱、對(duì)應數據表、對(duì)應字段、值源類型、值源URL、值源提供程序類名稱等）。)與數據庫同步。數據表的(de)簡單設計如下(xià)：

    2.3、數據規則的(de)配置
    使用(yòng)規則元素信息，管理(lǐ)員(yuán)可(kě)以爲系統中的(de)不同用(yòng)戶(角色)設置規則元素值，這(zhè)是數據查詢時(shí)的(de)篩選條件。規則元值數據源包括三種情況：情況①和(hé)情況②，管理(lǐ)員(yuán)需要填寫或選擇規則值，并将其存儲在數據庫中；情況③，根據當前登錄用(yòng)戶計算(suàn)值，即提供者在@data rule注解中計算(suàn)的(de)值。數據庫存儲的(de)規則與系統計算(suàn)的(de)規則相結合，即登錄用(yòng)戶的(de)所有數據規則。
    一個(gè)簡單的(de)配置界面如下(xià)：

    2.4 數據規則的(de)解析
    如上文所示，當前登錄用(yòng)戶的(de)數據規則有兩個(gè)主要來(lái)源：
    1. 存儲在數據庫中的(de)規則配置；例如位置[上海]
    2.需要系統計算(suàn)的(de)規則配置；如：[下(xià)屬人(rén)員(yuán)]
    3.合并兩種情況下(xià)獲得(de)的(de)數據規則後，可(kě)獲得(de)适用(yòng)于當前登錄用(yòng)戶的(de)數據規則集，流程圖如下(xià)：

    在這(zhè)兩種情況下(xià)獲得(de)的(de)數據規則如何兼容？如何将規則組合成複雜(zá)的(de)查詢條件？
    定義通(tōng)用(yòng)的(de)規則結構如下(xià)：
    {
    rule:[{
    field: “name“,
    operate: “equal“,
    value: “xxx“
    }],
    operate:“and“,
    group:[{
    rule:[],
    operate:“greater“,
    group:[]
    }]
    }
    數據庫存儲規則結構的(de)JSON字符串。合并時(shí)，反序列化(huà)JSON字符串，并使用(yòng)和(hé)連接由系統計算(suàn)的(de)規則對(duì)象。将合并的(de)規則結構解析爲一個(gè)簡單的(de)SQL語句并不困難。
    但是如何處理(lǐ)多(duō)表聯合查詢呢(ne)？
    在解析成SQL語句時(shí)，可(kě)以使用(yòng)表名+字段名的(de)方法。但是，當在查詢中使用(yòng)别名時(shí)，此方法無法正常工作。這(zhè)裏的(de)臨時(shí)處理(lǐ)方法是支持在解析期間傳遞别名。
    一個(gè)用(yòng)戶應該如何具有多(duō)個(gè)角色，不同角色應該如何爲同一規則設置不同的(de)值？
    例如，用(yòng)戶a具有角色role1和(hé)role2，其中：
    ROLE1應用(yòng)程序規則:[銷售區(qū)域][等][上海]ROLE2應用(yòng)程序規則:[銷售區(qū)域][等][重慶]
    那麽用(yòng)戶A合并後的(de)數據規則應該是：
    用(yòng)戶a的(de)适用(yòng)規則：（[銷售地區(qū)][等于][上海]）或（[銷售地區(qū)][等于][重慶]）
    即：一個(gè)用(yòng)戶對(duì)于同一個(gè)規則元素的(de)多(duō)個(gè)規則設置，應先使用(yòng)或連接後再與其他(tā)規則元素和(hé)連接..
    2.5、确定當前查詢适用(yòng)的(de)數據規則
    通(tōng)過以上規則的(de)配置和(hé)分(fēn)析，可(kě)以方便地得(de)到适用(yòng)于當前用(yòng)戶的(de)數據規則集。但是我們應該在收集中使用(yòng)哪些規則來(lái)過濾查詢？是否在查詢中啓用(yòng)數據規則篩選以及使用(yòng)規則篩選的(de)表應由開發人(rén)員(yuán)決定，類似于：
    XXXQuery(..）.withDataRule（“`table1`，`table2`”）；
    也(yě)就是說，表1和(hé)表2中配置的(de)數據規則用(yòng)于當前用(yòng)戶的(de)當前查詢。數據表中的(de)每個(gè)規則都應該支持是否在管理(lǐ)後台啓用(yòng)，這(zhè)樣理(lǐ)論上每個(gè)用(yòng)戶都可(kě)以配置每個(gè)數據規則。