【自然框架】之资源角色——列表过滤方案（思路篇）

本文链接：https://blog.csdn.net/jyk/article/details/4611561

名词解释

1、资源角色，我的理解就是资源过滤方案 + 角色。就是把资源过滤方案和角色结合在一起的东东。
2、资源：这里的资源指的是关系数据库里的记录。
3、资源过滤：就是按照一定的条件提取数据库里的记录。比如只提取自己添加的记录，只提取Kind=2的记录。
4、资源过滤方案：就是把这种查询条件以“方案”的形式保存起来，以便于和角色结合。

数据列表的过滤方案

      资源过滤又分为两种：数据列表的过滤和绑定控件（比如下拉列表框等）的过滤。
      其实不管哪一种，保存的都是查询条件，我把它们分为了两种，完全是为了便于操作，就是便于用代码的方式实现其功能。

      数据列表的过滤方案。这个是给列表页面使用的。比如业务员只能看自己添加的客户，业务部经理可以看到业务部的客户，总经理可以看到全部的客户。这里主要说的就是这个方案是如何实现的，另外一个方案下次再说。

这里根据我以前做过的一个项目来说明吧。

前几年给一个集团公司做了一个管理软件，这个集团有四个销售子公司，一个售后服务子公司，一个维修厂。他们是销售挖掘机、压路机这一类的工程机械，卖出去之后还要做机械的保养和维修等售后服务。
软件的主要功能就是记录业务员跑了哪些客户，哪些客户来买挖掘机，卖的是哪个型号（每一台都有自己的唯一编号，便于以后的保养）的，每一台机器的保养以及维修情况的记录。

第一个问题就是业务员和客户信息的问题。四个销售子公司是独立运营独立核算的，每个子公司都有自己的业务员，跑自己的客户，不过好在对于软件的要求都是一样的，做一个就可以了，不用做四套不同的程序。但是同时也遇到了一个问题。

1、业务员只能看到自己添加的客户，不能看到其他业务员的客户。
2、销售子公司经理只能看到自己所在公司的客户，不能看到其他子公司的客户。
3、总经理可以看到全部的客户。

程序是一个，但是不同的人（或者说是岗位），看到的记录却是不一样的，那么这时候就可以使用“列表过滤方案”。

这里主要目的就是为了说明“列表过滤方案”的思路，所以其他的就一切从简，比如表设计。表结构就只写出几个主要的表和主要的字段，其他的字段就暂时忽略，以免大家看着麻烦，呵呵。

客户表

字段名	说明	字段类型	字段大小
CustomerID	客户	int	4
客户名称	客户名称	nvarchar	30
客户地址	客户地址	ntext	16
AddedDate	添加日期	smalldatetime	4
AddedPersonID	业务员	int	4
UpdatedDate	最后修改日期	smalldatetime	4
UpdatedPersonID	最后修改业务员	int	4

部门表

字段名	说明	字段类型	字段大小
DepartmentID	组织机构	int	4
机构名称	机构名称	nvarchar	50
机构简称	机构简称	nvarchar	50

人员表

字段名	说明	字段类型	字段大小
PersonID	主键	int	4
姓名	姓名	nvarchar	50
性别	性别	nchar	1
出生日期	出生日期	smalldatetime	4
身份证号码	身份证号码	varchar	19

部门人员表。（关联表）

字段名	说明	字段类型	字段大小
DeptPersonID	序号	int	4
DepartmentID	组织机构	int	4
PersonID	人员ID	int	4

这几个表比较简单，我就不画关系图了。（打算下载一个PD，好好学习一下）。

依据这几个表，让您回答上面的三个问题，这个没什么难度吧。

1、业务员访问列表页面，添加AddedPersonID={PersonID} 作为查询条件。
2、销售子公司经理访问列表页面，添加DepartmentID={DepartmentID}作为查询条件。
3、总经理访问列表页面，不加查询条件作为查询条件。

{PersonID}、{DepartmentID}是什么意思？{PersonID}就是当前登录人的人员ID，这个ID是动态的，有人登录了之后才能确定，所以这里就用一个标签来占位了，运行的时候再做替换。{DepartmentID}就是当前登录人所在的部门ID。

我们在定义一个表来存放这些查询语句，这个表就是“数据列表的过滤方案”。

字段名	说明	字段类型	字段大小
ListCaseID	编号	int	4
FunctionID	关联节点	int	4
ResourceName	资源角色名称	nvarchar	50
ResourceDescribe	资源角色描述	nvarchar	50
SQL	过滤条件	nvarchar	200

过滤方案有了下一步就是和角色结合了。也可以叫做关联。我们建立一个关联表。一个角色可以访问多个功能节点，所以角色ID+节点ID 是联合主键，对于这种组合只能选择一个过滤方案

字段名	说明	字段类型	字段大小
RoleID	角色	int	4
FunctionID	节点	int	4
ListCaseID	列表过滤方案	int	4

我们可以建立三个角色：业务员角色、销售公司经理角色、总经理角色，然后再把这三个角色和过滤方案关联起来就可以了。当然了，这些是由程序来实现的，不需要直接到数据库里面修改数据的。

那么如何来提取这个过滤方案（也就是查询条件）呢？以前我写了一个BaseUserInfo类，这个类的目的是保存登录用户的一些信息的，我们可以增加一个函数来实现提取查询条件的目的。

【函数代码】

/// < summary >
        /// 传入节点ID，返回当前登录人访问该节点需要设置的查询条件
        /// </ summary >
        /// < param name ="functionID" ></ param >
        /// < returns ></ returns >
        public string GetResourceListCastSQL(string functionID)
        {
            string sql = "select [SQL] from V_Nature_User_GetListCase where UserID = " + this.UserID + " and FunctionID= " + functionID ;
            string listCase = DAL.ExecuteString(sql);

            if (listCase == null)
            {
                //没有设置列表过滤方案
                return "";
            }
            else
            {
                if (listCase.Length > 0)
                {
                    listCase = listCase.ToLower();
                    listCase = listCase.Replace("{personid}", this.PersonID );
                    listCase = listCase.Replace("{departmentid}", this.DepartmentID[0]);
                }
                return listCase;
            }
        }

调用这个函数之后就可以返回相应的查询语句，比如“AddedPersonID=3”。如果没有过滤方案者返回空字符串。

      如果您使用的是QuickPager分页控件的话，那么只需要把这个查询语句赋值给“TableQueryAlways”属性就可以了，这个属性在查询的时候，查询条件变更了也会有效的属性。相当于每次回发都会把查询条件赋值给分页控件。
      如果您使用的是其他的分页方式的话，那么这个查询条件也是有用处的吧。

附几个截图。（详细代码下次给出）

【给程序员用的管理过滤方案的页面】

【角色管理里面，通过“高级”选项，选择需要的过滤方案】可以给程序员用，也可以给客户的管理员用。

【V_Nature_User_GetListCase视图】

FAQ：
1、过滤方案只能和角色结合吗？
      过滤方案也可以和部门结合，也可以和其他的结合，也可以不结合直接使用，其实他就是给SQL语句找了一个存放地点，集中起来便于管理，使用起来也比较灵活。我把他和角色结合起来主要是为了方便嘛。

2、怎么没有代码了？
      这篇主要写思路，我感觉大家好像更喜欢思路，而不愿意去看代码，所以这里就集中说思路，下次再说代码吧。
可能我的代码很烂，但是我觉得我的这个思路还是可以的，也许您能够借鉴一下。