柠檬铺

TZHSWEET：请大家多多反馈问题，我已经在修改中了，已更新版本。。。。。。
如果大家遇到数据库附加问题，EF连接字符串问题，请自行配置,如果有bug反馈可以私聊，我的qq：409180955。
项目已经发布到Google Code上面了,大家如果需要直接去Google Code下载
主页http://code.google.com/p/tzhsweetsourse/
在上一节中我们总结了关于权限控制的方式,我们这一节讲解关于权限控制中角色权限的授予处理等等并做本系列的总结.
首先,我们来谈谈权限控制中角色权限的控制,上一节只是针对权限拦截中比较粗的控制,如果我们需要对每一个动作做细致的权限认证,我们仍然进一步设计权限处理.
比如:我们分配给一个角色只有浏览日志的权限,不允许他进行其他动作,针对这种细的粒度,我们就必须专门进行处理,就是关于角色动作验证的处理

当然,我们的数据库设计就必须就需要进一步改进.

这是我们的EF关系图:
主要看看关于tbModule,tbPermission部分,都是采用树形设计,为什么这样设计呢?
首先,我们必须要承认,Module也就是模块,应该是多层次的,就像我们的菜单,是很多级的一样,这种多层次需要我们设计成树形,授予权限,我们就可以很轻松的设计成树形进行处理.
其 次,关于tbPermssion,这个是权限,但是这个权限应该也是树形结构,比如我们设计一个菜单模块权限细分分为多种,增删改查,访问,等等,一个访 问可能对应多种ajax请求,比如一个ajax读取Grid信息,一个ajax读取Tree信息,如果我们要做细致处理就要对应做多级处理,虽然,小型项 目用不到,但是,我们的数据库设计拥有很大的灵活性.

权限可以细分,我们授权的时候,也不会不方便,只需要前端处理的合理,做好关联的处理,

但 是,如果一个Update可能有多个子集Action方法,比如Get方法,例如:部门信息管理,我们一个更新动作,是先Get部门信息,然后在进行修改 以后Update,所以,Get动作就是Update的子集操作,如果我们这个都控制,小型项目会变得太过复杂,怎么处理这种东西呢?
这时候我们之前的Attribute设计的多种权限处理就派上用场了.
首 先,对于多种ajax动作,如果不是对数据库很较大影响的,对于小型项目,我们根本不用管它,直接标记为只要登陆即可访问,比如 Get,GetGridTree之类的,读取信息这类的子集动作,直接给他个默认的LoginAllowView标记(登录即可访问),对于更高粒度,我 们当然要进行细致的控制.

这样,我们的小型项目的Action控制基本上就两级,也就是控制在增删改查这个级别,
如 果我们需要更高粒度的控制,只需要去掉LoginAllowView标记,在程序中对应添加Permission,并继续给我们的Action添加子集操 作,比如Add关联子集的那些动作,全部录入到数据库中,虽然过程会长一点,但是我们可以通过UI设计的更友好来处理它.

把每一个具体操作关联的Action都录入处理,我们就可以了,当然我们的数据库设计就必须合理,必须有ParentID字段,用来控制树形结构.
针对权限的处理我们就到一段落,接下来,上演关于LigerUI项目中学到的一个东西,公共查询组件的设计:
曾几何时我们拼接查询语句来设计各种搜索的高级功能,搜索,成了一块心病,这是一年前,刚开始学的时候做一个搜索的设计,拼接查询语句,
每一次的模块都是靠后台手工编码sql来设计逻辑

看到这里是不是已经吐了?????
我看了以前的东西都已经受不了了.....
也接触到了LigerUI关于Filter过滤器组件以及后台的设计,也发现一位牛人海南胡勇的组合搜索设计,

这给了我一个相当大的思路,就是设计一个通用组合搜索组件,提高复用率,设计一种解析翻译规则,我们只需要按照规则提供数据,把sql解析的工作交给组件.
这种设计是相当的震撼,而且web的开发方式可以把where放在客户端,可以在不改变后台代码的前提下,更大程度上去设计查询.
LigerUI的作者那个权限管理,我研究了好久,Filter也看了好久,这里谈谈心得:

主要的模块就是这几块:
FilterGroup:查询条件组合数组
FilterParam:查询参数集合
FilterRule:规则数组
FilterTranslator:翻译机(专门负责把数据以及条件翻译成sql语句)
重要:当然为了安全性考虑我们必须对翻译机过程中的数据做校验处理