权限设计方案.docx

权限设计方案.docx

《权限设计方案.docx》由会员分享，可在线阅读，更多相关《权限设计方案.docx（14页珍藏版）》请在冰豆网上搜索。

权限设计方案

权限管理设计一

∙博客分类：

∙设计

设计模式数据结构

应用程序权限设计

我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设计方案。

1.基于角色的权限设计

这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述

2.基于操作的权限设计

这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：

但是如果直接使用上面的设计，会导致数据库中的UserAction这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3

3.基于角色和操作的权限设计

如上图所示，我们在添加了Role，和RoleAction表，这样子就可以减少UserAction中的记录，并且使设计更灵活一点。

但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。

4.2,3组合的权限设计，其结构如下：

我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。

这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。

到这儿呢并不算完，有可能用户还会给出这样的需求：

对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。

5.对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没有权限的权限设计：

对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对Content和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根Channel什么级别的人有权限；这时候呢我们就可以定义些规则来判断用户权限，下面就是这种设计。

6.涉及资源，权限和规则的权限设计

兰亭序

永和九年，岁在癸丑，暮春之初，会于会稽山阴之兰亭，修禊事也。

群贤毕至，少长咸集。

此地有崇山峻岭，茂林修竹；又有清流激湍，映带左右，引以为流觞曲水，列坐其次。

虽无丝竹管弦之盛，一觞一咏，亦足以畅叙幽情。

是日也，天朗气清，惠风和畅，仰观宇宙之大，俯察品类之盛，所以游目骋怀，足以极视听之娱，信可乐也。

    夫人之相与，俯仰一世，或取诸怀抱，晤言一室之内；或因寄所托，放浪形骸之外。

虽取舍万殊，静躁不同，当其欣于所遇，暂得于己，快然自足，不知老之将至。

及其所之既倦，情随事迁，感慨系之矣。

向之所欣，俯仰之间，已为陈迹，犹不能不以之兴怀。

况修短随化，终期于尽。

古人云：

“死生亦大矣。

”岂不痛哉！

    每览昔人兴感之由，若合一契，未尝不临文嗟悼，不能喻之于怀。

固知一死生为虚诞，齐彭殇为妄作。

后之视今，亦犹今之视昔。

悲夫！

故列叙时人，录其所述，虽世殊事异，所以兴怀，其致一也。

后之览者，亦将有感于斯文。