`
starbhhc
  • 浏览: 633421 次
  • 性别: Icon_minigender_2
  • 来自: 深圳
社区版块
存档分类
最新评论

通用的权限管理系统的设计

阅读更多
有这样一句话:“传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能"。似乎他的那个权限设计也没有能够解决资源重用的问题。当然,如果它把资源文件分别存放在不通的文件夹中,通过url来根据权限来判断那就另当别论了。

我这个人比较懒,总是想用一个通用的方法,放在哪里都合适,因此在数据库的设计上费了一番脑筋了。其实,很多的权限管理系统都不太一样,因此,很多开发者开发出来的权限管理系统放在别的地方,就不一定合适了,往往需要重新开发,权限管理系统的结构不能变,变的仅仅是数据。在这样的一个思想的指导下,我们就想法让我们的结构不要变,尽可能的通用,其实结构在哪里,还是体现在数据库上了。四海同志说:“权限”,“组”和“人”。而这三种元素可以任意添加,彼此之间不受影响。

而我却认为,一个完整的权限管理系统应该包括:用户、角色、模块、资源这四个部分,在数据库的表设计上,这四张表叫做权限管理系统的实体表,只要把这四个实体表做出来,权限管理系统的架构就搭建完整了,这样的权限管理系统翻译成中文那就是:权限管理系统是判断(可能用判断这个词不是很准确)用户或角色对什么资源是否有什么功能的这样一个系统。这样设计出来的权限管理系统通用性、扩展性才够强,系统足够完整。四张实体表做好了,就意味着架构搭建好了,那么逻辑关系怎么办呢?我当时设计的时候用另外的4张表来存储他们之间的逻辑关系,总共8张表,四张实体表,四张逻辑关系表。 其它的权限管理系统可能少于8张表,一般通用性不会太好的。通常都是在完整的基础上做了下变化,有的利用继承来做,有的利用位运算,还有的虽然不通用,但是也是充分利用了自身的特点,一般都会少于8张表,但是一般翻译成汉语都不完整。通常为:用户对资源是否有什么功能、用户或角色对资源是否有权限等等。。。。切记,通用的权限管理系统无论是用户、角色、模块、资源哪个方面,都可以在不改变架构的条件下去动态的扩展,改变的仅仅是数据,而只要有这个思想,再结合自身项目的特点,相信设计和开发各种各样不通的权限管理系统不会有问题的。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics