1+1=2,0+0=0

@K.G
恩，我考虑过这个问题，我们现在的做法主要是把一个表作为一个资源来控制，自然控制的业务逻辑也是针对一个表的，若我们一个业务逻辑涉及到多个资源，也就是多个表，那我们就需要考虑这个业务逻辑主要是针对那张表的，譬如说我们添加人员信息，添加人员信息势必要涉及到给人员配置角色，那么就要涉及到人员表、人员角色对应表两个数据库表。一种方法是我们可以把两个业务逻辑分开，第二种是我们就把这个添加人员的业务逻辑看成是针对人员信息资源的业务逻辑，只考虑这个业务逻辑的主要针对资源，不考虑分支。这样的话也可以解决这个问题

@ronghao[匿名]
acegi我考虑过,对业务类权限控制不够灵活.

@Tendy
isValidPrivilege方法本身只要判断QUERY_OR_USE_PRIVILEGE就够了,至于代码是否简洁,我觉得不在我想讨论的范围

@errorfun
不是这样的，可以看到，我的权限中有一个是QUERY_OR_USE_PRIVILEGE权限，也就是最基本的使用权限，如果没有这个权限，那其他的就不用检查了，若有这个权限，我们就说他对该资源是有使用权，即有权限的。

另外我们其实也无需这样来判断用户是否具有该资源的操作权限，我们可以在资源表（T_ResourceInfo）中查看，若该角色没有对应到该资源，自然就没有权限了，这个类仅仅是用来在页面上判断是否显示某些元素，譬如添加按钮的时候用的，如页面上有这种标签的时候，我们就需要用到这个类中的CheckDeletePrivilege函数

@errorfun
判断是否具有权限，那么的确只要判断是否但与1就可以了，目前那个权限类存在的目的不仅是判断是否具有权限，还要判断是否具有添加的权限、删除的权限等等

另外我个人感觉如果每扩展一种权限就需要在里面加一个权值和一个函数，权值我们可以用其他方式来处理，譬如propeties文件，xml文件，数据库，常量类等，但函数我觉得挺有必要增加的的：如增加上传权限，我们需要加个函数checkUplodaPrivilege()，我觉得是有必要的，但如果您有更好的办法，我们可以拿出来探讨一下：）

@coder
在上文中我提及到：“可以添加进去组(group)、系统(system)、组织(organization)，建立起一套属于你自己的完整的权限解决方案，作为系统无关的模块去套用到每个你所架构的应用中去”
原理大同小异，我只是将其中的我觉得可以拿出来讲的部分进行抽丝剥茧，起个抛砖引玉的作用，早先我同事设计过一套极其复杂的权限数据库，其中涉及到安全密钥、指纹识别、防火墙设定等等，但无论多复杂，都无法逃离角色-资源的关系，所以我仅仅抽出其中部分来叙述，如若还需扩展，也很方便

@errorfun
1，呵呵，上传文件仅仅是添加操作，我们只是获得request流，解析流中数据，并且添加入数据库，如果您硬要认为这个操作就是添加数据，我觉得也不无道理，但客户的需求是这样的：高级系统管理员角色可以一次性用excel导入一大批数据，普通的管理员不能进行这样的导入操作，只能逐条添加，于是乎，您认为的这两种“添加”操作在我们的系统中被看成是不同的两种权限。

2，您提到“即然你都可以看到源数据了，饼图，曲线图却不让人看，还让人家自己去画不成？”，您的这个想法无可厚非，但目前的需求是这样的：普通管理员只能看到数据，即查看源数据，而领导要求只对他开放数据汇总成图形的功能，也就是数据统计后的图形查看功能，领导不关心源数据，只关系数据的统计结果和比例

3，我觉得您的理解固然没错，但不同的客户的需求不同，您所说的内容是针对需求的理解问题：）

呵呵，我刚起床，下面就发布代码，如果不结合代码，看这样的数据库设计或许会很疑惑难懂

1，楼上的或许还是没有看懂我所说的权限设计，倘若你的‘增加权限’设置为1，而a这个角色当前所拥有的权值是30，那么只需要1&30进行二进制运算，不等于0，则说明有增加权限，没有你说的那么复杂。

2，另外你所说的在页面嵌入java代码我不知是从何判断，我是做好了一个现成的权限标签，包在你需要判断的页面元素之外，如你可以在页面上这么写：
<privilege scope='session' operation='create' beanName='userinfo'>
<input type="button" value="添加">
</privilege>
这样系统会自动为你判断当前用户是否具有添加权限，从而为你设置页面上是否显示添加按钮

3，权限是人定的，我可以把对这个资源的增加定为一种权限，上传定位一种权限，客户可能要求此人只能上传不能增加（我说的上传是指以excel文档的形式上传上来，解析其中的数据并添加入数据库中），都是有可能的，可能你还是认为他们都属于添加操作，但用户就是要求你不能添加，只能上传，只有它指定的人才能添加。另外我说的报表，不仅仅是察看，我们可以定义一种形式的pdf报表，将数据库中的数据导出到pdf，并形成饼图、曲线图等，这和查看可以说完全是两种不同的操作，所以权限是没有限制的，也就是说实际系统中对一个资源的权限可能最多也就10种撑死了，但我们需要做到的是：无论对这个资源的权限如何扩展，我们都可以应对，不是么

前一段时间做一个工作流，用的是Websphere Process Server，由于中国式的工作流与国外的大不相同，诸如领导审批类的人工审批节点占据了大多数于是我们的团队遇到了困难，即一个人审批过后接下去可能要接着审批，也可能就交给下一个人来审批，可能此人审批完毕后要将控制权交还给流程引擎，而流程引擎却无法让我们的页面自动跳转，为此我们咨询了IBM美国实验室的WPS高级架构师，他说IBM将在2006年底推出WPS的最新版本，其中引入了PageFlow的概念，由页面来驱动流程的进行，一番讨论后对PageFlow有了一些了解，今见此文，更有了一些自己的见解，十分感谢作者。

另外对于权限的记录来说，用数据还是xml文件来记录我认为主要不在读取速度上来区分，因为大多角色权限信息我会放入内存中，所以xml还是数据库来记载对我来说无所谓，但有一点区别是致命的，就是当你修改权限信息时，你需要修改相应的纪录，很明显修改数据库记录要比修改xml文件来的方便，io操作还是挺让人~~~嘿嘿

呵呵，我目前所用到的权限种类繁多，所以权值也很多，权值基本的计算公式我就用了2的n-1次方，这样权值可以无限扩展，无论是增、删、改、查、报表、上传、下载，我都会分配一个权值，如果一个角色拥有多个权限，则这个角色的权值为他所拥有的所有权限的权值的和，我将权值的和以16进制的形式记录到库中，基本上来说一个用户对一个资源在数据库中只有一条权限记录

首先对大家的关注表示感谢^_^
另外由于我不会在评论信息中加载代码，所以我将本文中的标题后面加上了(1)，我将在我随后的几篇随笔中分别谈一下我的权限分配的相关数据库设计、数据库与权限关联配置、界面权限控制和底层拦截机制，小文确是抛砖引玉，谢谢关注~~：）