关于权限的一些想法

时间:2022-07-24
本文章向大家介绍关于权限的一些想法,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

准备做权限的时候,有两套方案。一·在数据库保存所有的那些需要控制的点叫做权限表。基本就是一些id。然后一个角色表,角色对应权限,用户对应角色。

第二种是以前在一个项目中见过的权限控制方法。用户-角色-权限,这些不变,有变的是:权限不用一堆数据表示:使用二进制即类似"01011100110"这样的字符串来表示,在用户拿到这些数据以后使用同一的方式进行解析,比如前四个表示某个窗体,某个页面,前四个中的第一个表示添加0是可用1是不可用。

初步分析两者之间的差异,先说共同点。都有一些写死的东西。官方一点的话叫做,扩展性较差。

差异:第一个结构清晰,维护起来比较容易。但用户频繁的查询,增加了不必要的IO操作,性能方面会差很多,尤其web程序。

第二中:可读性差。维护起来麻烦。可能需要在对应的结构数据中添加一些必要的信息才能达到扩展的可能,一旦出错,调试也是个麻烦事。优点就是占的地方小,如果用到web中可以很大程度上的提高性能。对于某用户的权限信息,可能只有不到1kb.

--------------------------------------------------------------------------------------------------

那么理想中的权限应该是可以扩展的,而且在网络传输中尽可能的减少传输内容,最好是在这个基础上再减少IO的操作,让各部分的负载能达到某种意义上的平衡。当然了,最重要的还是可靠稳定以及拿到任何地方都可以使用。

可扩展,目前能想到的貌似也只能是将数据像类一样保存,将来若是某个页面或者窗体添加了某个需要控制权限的按钮只需要在对应的类里边加上要给属性就ok.数据存储上吸取第二种方式的那种存储。但不能完全复制。在它的基础上做改动,想来想去貌似只有json格式的数据能同时满足这两种方式的操作。。

结构化满足,能被反序列化。能扩展,而且,修改不会对之前的数据产生影响。当然这个里边该考虑的还有json支持的数据量的大小。

还有一个容易忽略的问题,就是如何将这些信息定义到一个类里边,或者某个可结构化的东西中去。将来如果要给某页面加个按钮,实现一些无关后台的东西,但同时要求只有某人才能看到一类的需求。重新修改程序当然可以做到,但希望能把这个东西做成可拆卸的。只修改某个配置文件,以及页面就完美实现。

到这里我想到了xml。如果我能将网站,或者程序的结构信息保存到xml中。自定义一种书写规范,将来按照这样的方式在开发的时候将所有信息都完整添加到这个文件中结构类似下边这样:

<project>
    <pagename>
        <元素ID/>
        <元素ID/>
    </pagename>
    <pagename>
        <元素ID/>
        <元素ID/>
    </pagename>
</project>

在权限分配的页面中读取这个xml文档。被选中的节点,在保存的时候放到json串中。放到数据库里面...

如果这么做,一个项目中权限只会有一个xml,一个页面维护这个xml(开发时,添加节点,删除),一个权限赋值(修改)的界面。数据库 用户表中添加一个角色(varchar),存放用户的角色属性。一个用户可能会属于多个角色,这里的大部分数据只会是一个数据。不排除有多个角色的用户,但这样的数据会非常少,所以这里只需要用逗号隔开,程序那边做点处理就好了。角色表中会有一个字段来保存该角色对应的json数据。将来用户登录的时候获取到对应的角色对应的json数据。通过一点点计算就可以控制到每个页面的元素展示,显示还是隐藏...

到这里权限功能已经算是基本搞定了。这需要注意的就是xml中的pagename,元素id,与对应页面的耦合度高,一处页面名称的修改直接会导致权限控制失效,id的修改也会导致。一般情况下,页面的名称是不会变的。会变化的可能只会页面中的元素ID.可以添加额外的标签描述Attribute。来判断对应元素的显示隐藏..