用户权限管理设计.docxVIP

用户权限管理设计 用户权限管理设计 用户权限管理设计 用户管理权限设计一直是大家讨论的热点，因为几乎涉及到每一个开发的业务系统。我找了很多很多的资料，大家的核心基本上都是一样的:基于角色管理. 用户，角色，模块，权限的相互组合，就可以形成一个强大的权限管理系统。 最近在一个项目中设计的一个用户权限的设计，很乐意与大家一起讨论及分享. 我的设计思路或者说是我想要实现的功能 1.用户的权限通过角色来控制,一个用户可以拥有多个角色. 2.用户拥有不同角色时，其权限应该是多个角色相互的补集. 3.一个角色拥有多个模块 4.用户的前台菜单显示根据角色所拥有的模块所决定，不同的用户在前端显示的操作菜单是不一样的。 5.页面中的功能按钮根据模块中所包含的功能所定义，通过模块及角色所拥有的权限进行控制 6.可看某个模块有哪些用户，哪些对应角色,并对其进行特殊权限设置. 7.可以针对单个用户进行特殊设置 我在我的Project中，基本上达到了以上的效果及功能，但在实际过程中发现有些不足之处。因为整个权限设计是基于数据库来设计中，所以数据的读取当数据量大时（我所说的数据量是以万以上来计）可能对性能有一定的影响。但对于一般来说，几千用户之类的我想还是可以承受的。我会在后面说明不足之处。 1.首先,设计数据库. 数据库的设计其实我估计大家都很熟悉了 基本表：用户表，角色表，模块表，功能表,管理员表.如果涉及到企业性质的，可能会根据需要加上组织结构表，群组表等其它辅助表 (我的模块表考虑了子模块的因素,所以会有深度，父模块ID这两个字段，在后来开发过中，由于思路的转变,IsRootModule,FunctionCode我都没有用到,为了让整个权限系统通变得更通用，我都将其单独设计成了另一个表） 功能表（功能表就是模块对应的功能：增加，删除，修改，详细，列表，浏览，导出，导入之类的） 业务表：用户-角色表 模块-功能表 角色-模块表 要实现一个用户多个角色(1 to n),一个角色多个模块(1 to n),一个模块多个功能(1 to n)，那就得加上几个相关的业务表，之前考虑用视图去实现，我个人之见,视图最好只用来读取数据，不要用来进行数据操作.后来证明是不可取的，这里要注意的就是在实际的业务操作中，应该尽量避免重复的数据录入. 这些表都很简单，但却很关键 大家可以看到，表结构很简单，字段也很少，设计也差不多。都是将相关联的字段ID取出来做数据存取。 视图：用户-角色-模块-功能视图 可能大家会觉得很奇怪，为什么这里出现member_role呢。因为我们在数据表中只存取了ID值，而对应的RoleName字段并没有包含其中，这里的视图就是获取关联表中其他所需要的字段数据了。另外两个视图大家看名字应该就知道他的用处了。 存储过程：各自表的增加，删除，修改，及列表数据. 判断是否存在相同的数据 （CUDLIS-Create, Update,Delete,IfExist,Show,List) 存储过程我就不一一列出了，很简单的，你只要写出下面这些基本上你在开发过程就不会有太多问题了. 注意的是：在相互关联的业务表中，最好能对数据插入进行重复数据判断（用户角色表，模块功能表，角色模块表，尽量避免重复的数据插入）我把大致需要实现的业务列个表给大家参考: 用户表:(Insert ,Update ,IfExist ,Show, Delete) 用户角色表:(Insert ,Update,IfExist,Delete,RoleListByUserID,UserListByRoleID) 角色表:(Insert,Update,IfExist,Show,Delete) 角色模块表:(Insert,IfExist,Delete,Show,RoleListByModuleID,ModulistByRoleID) 模块表:(Insert,Update,IfExist,Show,Dlete,ListByRootModuleID,ListByModuleLevel) 模块功能表:(Insert,Update,Delete,FunctionListByModuleID) 针对用户直接获取其所有的权限时，应该有个单独的Procedure从视图中Member_Role_Module_Function中获取其对应的数据，这样就可以得到想要的东西了。 数据库设计部分应该就这样差不多了。我想这应该是通用的。在实际运用过程中，我个人