用户权限管理设计[插图]

我很高兴与您讨论和分享在最近的项目中设计的用户权利的设计。设计思路就是我的设计思路或者我想实现的功能。1.用户的权限由角色控制，一个用户可以有多个角色。2.当一个用户有不同的角色时，他的权利应该是多个角色的互补集合。3.一个角色有多个模块。4.用户的前台菜单显示由角色拥有的模块决定，不同的用户在前端。5.页面上的功能按钮是根据模块中包含的功能定义的，由模块和角色拥有的权限控制。6.您可以看到模块拥有哪些用户和相应的角色，并为他们设置特殊权限。7.您可以为单个用户设置特殊权限。在我的项目中，基本实现了以上的效果和功能，但在实际过程中发现了一些不足。因为整个权限设计都是基于数据库的，数据量大(我说的数据量是一万多)的时候，数据的读取可能会对性能产生一定的影响。但总的来说，成千上万的用户等等，我觉得还是买得起的。后面我会解释缺点。数据库的基本设计：1。首先，设计数据库。其实我估计大家对基本表都很熟悉：用户表、角色表、模块表、功能表、管理员表。如涉及企业性质，可根据需要增加组织结构表、集团表等其他辅助表。

行政长官

角色

模块(我的模块表考虑了子模块的因素，所以有两个字段：深度和父模块ID。在后来的开发中，由于思维的转变，我没有使用IsRootModule，FunctionCode。为了让整个权限系统更加通用，我单独设计成了另一个表)。

菜单(菜单是一个模块对应的功能：添加、删除、修改、详细、列表、浏览、导出、导入等。)。

业务表：用户-角色表模块-菜单角色-模块表要实现一个用户的多个角色(1到n)、一个角色的多个模块(1到n)和一个模块的多个功能(1到n)，必须增加几个相关的业务表，以前认为是用视图实现的。在我个人看来，视图最好只用于读取数据，而不是数据操作。后来证明是不可取的。这里需要注意的是，在实际业务操作中，应尽可能避免重复录入数据。这些表很简单，但它们对用户角色： 非常重要。

角色模块：

模块-功能：

可以看到，表格结构非常简单，字段很少，设计也差不多。就是取出关联的字段ID进行数据访问。视图：用户-角色-模块-功能视图。

大家可能会觉得很奇怪为什么这里会有一个member_role。因为我们只访问数据表中的ID值，对应的RoleName字段不包含在其中，所以这里的视图是获取关联表中的其他必填字段数据。在另外两种观点中，你应该通过看名字来知道他的用处。存储过程：添加、删除、修改和列出各个表的数据。我不会列出用于判断是否存在相同数据的存储过程(cud lis-创建、更新、删除，如果存在，则显示、列出)。很简单。基本上，如果你写了下面这些，你在开发过程中就不会有太多的问题。注意：在相互关联的业务表中，数据插入最好判断重复数据(用户角色表、模块功能表、角色模块表，尽量避免重复数据插入)。我将列出需要实现的服务供您参考：用户表：(插入、更新，如果存在，显示、删除)用户角色表：(插入、更新，角色表：(插入、更新，如果存在，显示、删除)角色模块表：(插入，如果存在，删除、显示，rolelistby moduleid，ModulistByRoleID)模块表：(插入、更新，如果存在，显示、删除、listbyrootmoduleid)数据库设计部分应该差不多是这样的。我认为这应该是普遍的。在实际应用的过程中，我个人认为应该有一些改进：1。在模块和功能部分，模块对应的功能可以以字符串的形式存储在一个数据字段中，这可能会节省更多的时间，给你的代码编写带来更多的便利(主要是可以使用split()来代替频繁的数据采集服务)，这是我在最初设计时没有想到的。一个小失误。2.鉴于N级模块的权限显示，我没有考虑如何让父模块继承子模块的权限，但是我觉得应该可以用IsRootModule字段来做一篇文章。很遗憾，我还没有想到如何纠正这个字段。子模块多的时候，前面UI会不会显示慢？我没有参加这次考试。有一定的风险，但是我还没有想到或者实现一个好的方法在前台UI展现出来。我能想到的是像GridViewTree这样的好方法。这个权限设计已经在我的项目中使用过了，暂时没有发现问题，对我以后集成其他系统也很有帮助。至于如何在C#中实现业务，我个人认为只要知道如何集成数据库，C#中的业务实现只是一个取数的过程。我将在下一部分与您分享讨论。