企业应用：浅谈 “数据权限” 和 查询 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 呢？

第一种：

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

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

第二种：

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

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

我更喜欢这种风格。

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

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

备注

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