企业应用：浅谈 “数据权限” 和 查询 API 设计

背景

多数企业应用都需要对数据权限进行控制，如：某个用户只能看到某个范围的数据（数据行）、某个用户只能看到某几列数据（数据列）。本文以数据行级别的权限控制为范例，谈谈如何设计权限模型和查询 API。

权限模型

结合自己的项目需求，可以省略掉“数据角色”，直接让“用户”聚合“数据权限”，也可以只保留一个“角色”，让“角色”聚合“操作权限”和“数据权限”。

可扩展的数据权限模型

伪代码示例

    class SessionInfo
    {
        public Guid UserId { get; set; }

        public Guid DepartmentId { get; set; }
    }

    interface IDataPermissionProvider
    {
        string CreateSQL(SessionInfo sessionInfo, Dictionary<string, object> args);
    }

    [DisplayName("我的")]
    class DepartmentDataPermissionProvider : IDataPermissionProvider
    {
        public string CreateSQL(SessionInfo sessionInfo, Dictionary<string, object> args)
        {
            return String.Format("( CreateUserId = '{0}' )", sessionInfo.UserId);
        }
    }

    [DisplayName("指定部门")]
    class MySelfDataPermissionProvider : IDataPermissionProvider
    {
        public string CreateSQL(SessionInfo sessionInfo, Dictionary<string, object> args)
        {
            return String.Format("( DepartmentId = '{0}' )", args["DepartmentId"]);
        }
    }

草图示例

说明

很容易将这部分“插件化”，如支持“自定义”，然后显示一个输入框，可以输入：“Price > 130”。

如何设计查询API？

先看两个用例

上面两个用例，对订单有两种查询需求，我们如何设计这种查询 API 呢？

1. 第一种：
   

       class QueryService
       {
           public QueryResult Query(UserCase userCase, DynamicQuery query)
           {
               // 根据 userCase 决定是否或如何动态的追加数据权限。
               return null;
           }
       }

   需要根据不同的 UserCase，决定是否追加数据权限，如：A 用例需要数据权限，B 用例不需要，UserCase 可能是“当前请求的模块名字”或“当前请求的URL”。

2. 第二种：
   

       class QueryService
       {
           public QueryResult QueryA(DynamicQuery query)
           {
               return null;
           }
   
           public QueryResult QueryB(DynamicQuery query)
           {
               return null;
           }
       }

   我更喜欢这种风格。

上面的 DynamicQuery 并不是“万能的查询条件”，而是满足某一用例的不同查询组合的一种“规约”，很多系统都提供“万能查询”，也算是一种特殊的“规约”了。

另外需要注意的是：一个用例会有多种查询需求的（或者叫查询组合）。

备注

仓促成文，有这方面经验的朋友请留言批评。