这次要写一整套的权限方面的文章了,无论我的想法好与不好,先写出来请大家来评判。这个系列我要详细的说明我的权限的思路、想法、实现方式、代码和Demo。可能有人会说,通用是达不到的,最多只能无限接近。恩,对于我来说,能够无限接近就可以了,当然我知道如果要达到这个目标并不是一件容易的事情,有难度才有挑战,才有意思。所以我会在权限方面不断的努力,不断的无限接近通用。也请大家多多帮忙,毕竟一个人的力量是有限的。
通用权限想要写的文章目录:(这是第一章)
1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表(表单、查询)
9、 权限的验证
10、 资源方面的权限
11、 角色管理的程序(给客户用的)
12、 权限下放
13、 个性化设置
简介
(以下都是我的个人理解,不一定正确。如果有误请多多指正。)
1、何谓权限?
我说一下我的理解,权限从字面上看就是“权力的限制”。在软件里面,权力是什么呢?就是一种操作、一个功能点。那么在软件里面权限就可以理解为“对操作(功能)的限制”,说白了就是某人能不能做某件事情、某个操作。
2、何谓角色
角色是权限的集合,一个角色可以拥有若干的权限,一个人拥有了这个角色,那么就拥有了这个角色所拥有的权限。就是方便设置权限的一种产物。
3、何谓用户组
这个应该来自于windows操作系统吧,windows操作系统里面有用户和用户组,给一个用户组设定好权限后,用户组里面的用户就具有了用户组的权限。我觉得应该和角色是一个意思。所以我的通用权限里面只有角色,而没有用户组。
4、如何来通用?
我所说的“通用”,就是不写死在代码里面,需求有变化的时候,尽量不用修改代码就可以让客户满意。我的思路就是把权限和代码分离开来,写程序的时候不用关心权限的事情,只要“切成小片”就可以了。而设置角色的时候也不用考虑程序具体是什么样子的,或者说不会由于程序不适合而需要再去改程序。
5、权限不仅是操作,还有资源
前面说了,权限是对某个操作的限制,如果只有操作那就好办了,但是问题是除了操作之外还有资源。比如CMS里面的客户信息,业务员只能修改自己添加的客户,不能修改和查看其他人添加的客户信息;而业务一部经理可以查看业务一部的客户信息,不能查看其他业务部的客户信息;业务部的总经理可以查看全部的客户信息。业务员的可以根据UserID来过滤,而经理级别的就要用部门ID来过滤了。这就比较麻烦,如何才能把资源的权限给抽象出来呢?这个好像就不太容易了,而且这个还不是最麻烦的,更麻烦一点的是,比如张经理是业务一部的经理,但是他不仅可以查看业务一部的客户信息,而且还可以查看业务二部的客户信息,为什么呢?因为他还兼任业务二部的经理(当然还可以是其他原因)。更复杂的情况相信还有很多。
另外我刚才说的只是资源权限的一小部分,而我经历的项目不多,而且也不是很复杂,所以这方面积累的经验还远远不够,经验不够就不好抽象了。本来想去某人那里去学习点经验的,但是某种原因不想去了。所以嘛,在这里借此机会,向大家发个请求:如果您遇到了资源权限方面的需求,还请您把客户的需求告诉我,我好积累更多的经验(已知条件),好把资源权限做得更好,谢谢大家了。当然了,我想出来的办法都会写到我的blog里面的。
实现思路和数据库设计
因为我是老脑筋了,面向数据库的,所以最先想到的就是如何来设计数据库,所以下面就说一下思路和数据库。
权限涉及到的部分:人员、组织机构、项目描述、角色。其中角色是权限自己的,而人员、组织机构、项目描述则是相关联的部分。
“项目描述”是什么?
您可能会对项目描述比较陌生,这是什么东东?这个对于我来说是非常重要的,如果没有这个项目描述,我是做不到“通用”的。(注意:我是说我不用项目描述做不到通用,并不是说其他人也都做不到。)
我是喜欢使用数据库的,所以这个权限我也用数据库的形式来体现了。先画一个图来看看上面四个部分的关系。
下面是四个部分里面的表的关系。
【人员】
【角色】
【组织机构】
【项目描述】
这一章就这样结束了,没有什么具体的东东,希望没有倒大家的胃口。下一章就会介绍详细详细介绍这几个数据库,包括思路、用意和用法。争取在一周内把权限都写完。您的留言就是我的动力,谢谢!
如果您想看数据库说明文档(人员、角色、组织机构、项目描述、还有上一篇里的图)的话,可以到这里下载:http://www.cnblogs.com/jyk/archive/2009/06/06/1497616.html