具有权限控制的通用菜单的设计与实现.docx
《具有权限控制的通用菜单的设计与实现.docx》由会员分享，可在线阅读，更多相关《具有权限控制的通用菜单的设计与实现.docx（19页珍藏版）》请在冰豆网上搜索。
具有权限控制的通用菜单的设计与实现
具有权限控制的通用菜单的设计与实现
摘要
本文通过分析Windows桌面应用程序中权限控制和菜单的基本功能，利用C#程序设计语言及SQLServer数据库技术给出一种具有权限控制的通用菜单的解决方案并加以实现，形成一个可以运用到实际系统中的通用应用程序；并且从需求分析、系统分析以及模块化设计等方面加以阐释。
关键词：
应用程序；权限控制；菜单；C#；数据库
一、系统概述1
二、有关概念2
三、系统分析 3
（一）需求分析3
（二）系统分析6
（三）系统分层结构7
四、系统设计8
（一）系统数据库设计 8
（二）系统流程图设计12
五、系统实现13
（一）系统数据库实现13
（二）系统程序实现13
六、关键技术18
（一）使用递归调用法遍历多级菜单对象18
（二）采用三层（表示层，业务逻辑层，数据访问层）结构模式组织设计程序。
18
七、总结19
致谢20
参考文献21
一、系统概述
目前基于Windows的桌面应用程序在企业、机关部门、学校、医院等各种行业中都起着举足轻重的关键作用，它可以大大提高工作效率，节约成本。
因此Windows桌面应用程序的快速开发就成为各个行业的迫切需求。
而在当今Windows桌面应用程序的实际应用中，用户权限控制功能和菜单功能都是应用程序中最基本的功能；在应用程序的开发中，权限控制模块和菜单模块也处于程序整体设计的核心地位。
所以，非常有必要把权限控制和菜单模块在应用程序的开发中单独提取出来，进行详细而周密的分析，形成相对独立且通用的程序模块组件，以便轻易地重用于其他实际系统中。
这样，可以大大提高应用系统的开发效率，加速应用系统的开发周期，节省应用系统的开发费用。
同时也增强了软件复用程度，降低了软件耦合度，对于Windows桌面应用程序的开发有非常重要的实际意义。
二、有关概念
Windows桌面应用程序：
使用Windows窗体设计器来设计窗体，创建基于MicrosoftWindows的应用程序和客户机/服务器应用程序。
权限控制：
管理系统中分配给不同用户不同的访问权限，即控制用户是否拥有系统中各功能的使用权。
菜单：
通过存放按照一般主题分组的命令将功能公开给用户。
C#：
C#（读作Csharp）是一种编程语言，它是为生成在.NETFramework上运行的多种应用程序而设计的。
C#简单、功能强大、类型安全，而且是面向对象的[3]。
VisualStudio2005：
VisualStudio是一套完整的开发工具集，用于生成ASP.NETWeb应用程序、XMLWebServices、桌面应用程序和移动应用程序[3]。
SQLServer2005：
MicrosoftSQLServer2005是用于大规模联机事务处理（OLTP）、数据仓库和电子商务应用的数据库平台；也是用于数据集成、分析和报表解决方案的商业智能平台[4]。
三、系统分析
（一）需求分析
1、需求概述
项目名称：
通用权限菜单模块（CommonMenuModule）,简称为CMM。
项目需求：
系统默认设定一个超级管理员帐户sa及其密码，并且sa账户是唯一且不可删除的，超级管理员账户具有系统最高权限（即所有功能权限）。
初次登陆系统在没有建立任何账户时，用户可以使用超级管理员账户登录系统。
本系统有两种权限模式供用户选择，分别为用户权限模式和角色权限模式。
在菜单中单击哪种模式就默认当前使用这种权限模式。
用户模式：
对于普通用户，登录后可以新建用户账户并激活帐户，未被激活的账户即使拥有菜单权限也无法登陆系统。
新建的用户帐户可以为之一次性分配主菜单和导航子菜单项的权限状态，保存后菜单权限立即生效；即当前被修改权限的账户在登录后只能看见刚才被分配到的菜单项，而未分配权限的菜单项不会显示并且也不可用。
角色模式：
由用户新建角色，并为新建的角色分配菜单项的权限状态。
然后可以给每一个账户添加相应的角色关系，从而使每一个用户都继承某种角色的权限，实现用户权限按角色分配。
角色可以有多个，且每种角色的各个菜单项权限状态可以不同，达到按角色分配多个账户的目的。
此外，在用户权限模式中的各个账户或角色权限模式中的各个角色的菜单项标题也可以自定义并修改，方便用户的使用。
对于开发人员，登录后不仅拥有普通用户的所有功能，还可以对主菜单项、导航菜单项和导航菜单子项进行添加、修改、删除等操作。
而且这些操作都无需在代码或数据库中完成，都是以友好界面来表示的，甚至在技术上只要求会操作计算机的人员即可完成。
2、功能模块需求分析
通过对整个系统需求和流程的分析，得到系统的功能模块图（如图1）。
图3-1系统功能模块图
用户登录模块：
通过用户输入账户名及密码验证当前用户是否有登录系统的权限。
验证成功，进入主界面；验证失败，给出提示信息。
角色权限模式管理模块：
用户可以添加角色，修改和删除在角色列表视图中选定的角色名称。
并可以通过对菜单项权限树形视图中各个项的勾选来完成对当前选定角色名称的菜单项权限状态的具体配置。
相应的勾选状态也会实时地在菜单项权限列表视图中更新选择。
用户也可以更改当前选定角色名称所对应的。
3、各个菜单项的名称
还可以为已存在的账户名设置已添加的角色，设置好角色后，此角色所对应的各个菜单项的权限也随之赋予给该账户名，当然用户也能在权限管理列表视图中删除选定的权限关系。
在权限关系列表视图中用户还可以对各个账户名所对应的角色名进行调整，相应的角色名所对应的各个菜单项权限也会同步更新。
用户权限模式管理模块：
用户在此模块可以添加账户名称和密码，并可以修改所对应账户的激活状态，当状态为激活时，无论有无菜单项权限都可进入主界面；当状态为未激活时，无论有无菜单项权限都无法进入主界面，但有相应提示信息。
当然用户可以删除所选定的账户。
通过菜单项权限树形视图对各个项权限状态的设置，用户可以给当前所选定的账户名分配各个菜单项权限,菜单项权限列表视图会实时更新用户所分配的各个菜单项的权限信息，在此视图中还可以更改各个菜单项名称以适应不同用户需要。
以下三个有关菜单管理的模块主要用于开发人员在系统开发阶段以及日后维护新增功能时对主菜单、导航菜单和导航子菜单的配置。
对于普通用户可以通过菜单权限设置屏蔽这三个模块的功能。
主菜单管理模块：
开发人员可以通过界面的方式维护主菜单，包括执行对主菜单项的添加、修改以及删除等操作。
在添加或修改新菜单项时，可以通过选择已添加的菜单项作为父菜单，或是直接创建为根菜单项。
导航菜单管理模块：
与主菜单管理模块类似，开发人员可以以界面方式维护导航菜单，并对导航菜单的部分属性进行修改。
如图标或尺寸等。
导航子菜单管理模块：
与导航菜单管理模块类似，开发人员同样能够以界面方式维护导航子菜单，并对导航子菜单的部分属性进行修改。
当添加或修改一个导航子菜单项时，可以从所有主菜单项中选择导航子菜单项的名称，并且可以选择导航子菜单项的父菜单。
用例需求分析
在需求分析时，用例图（UseCase）是一种常用的建立业务流程模型的方式。
根据需求，可以得到通用权限菜单模块系统的业务流程用例图，如图3-2所示。
图3-2系统用例图
从图3-2中可以看到本系统包括普通用户和开发人员两种角色，这些角色分别进行不同的操作，根据这些操作建立了相应的用例，对各个用例的详细描述如下。
用户登录用例：
用户登录验证成功后，方可进入主界面进行下一步操作；如果登录失败，则重新开始本用例。
用户登录时需要输入账户名和密码，账户名和密码的填写只有与管理员设定一致时才能通过验证。
用户修改密码用例：
用户需要输入原密码、新密码、重复新密码，只有原密码匹配且新密码和重复新密码相同时方可将新密码替换为原密码。
用户模式权限管理用例：
用户需要添加新账户时，可以使用本用例。
需要输入账户名、账户密码、重复账户密码并可以选择所添加账户的激活状态，默认为未激活。
只有账户名不与原有账户名重复，账户密码和重复账户密码相同且密码符合简单安全规则时方可建立新账户。
当选中某个账户名时可以执行删除，赋予菜单项权限状态，修改相应菜单项名称等操作。
修改菜单项名称时菜单项名称不能为空，否则修改失败。
此外，当用户希望选择使用用户权限模式时，也可以在本用例中实现。
角色模式权限管理用例：
用户需要使用角色权限模式时，使用本用例。
用户可以新建角色名称，为角色赋予菜单项权限状态，删除当前选定的角色名称，并修改当前选定角色名所对应的菜单项名称。
在添加新角色时，系统默认角色名称为“未命名”，并且角色名称不能相同。
用户也可以为账户设置或修改角色。
一个账户只能对应一种角色，而一种角色可以适用于多个不同账户。
当然可以删除角色与账户这种对应关系。
需要注意的是删除角色时，如果已经为角色分配了关系，那必须先手动删除所有分配了的关系，然后才能删除此角色；否则删除角色失败。
开发人员主菜单管理用例：
开发人员在设计系统时，需要添加、修改主菜单，与主菜单有关的操作需要使用本用例。
添加新菜单时，需要输入菜单项名称、菜单项文本等信息，然后可以选择父节点或根节点，已建立相应的菜单项。
选择父节点时，不能同时选中根节点。
菜单信息也不能为空。
开发人员导航菜单管理用例：
与主菜单管理用例类似，开发人员对导航菜单进行添加、修改、删除等操作时使用本用例。
导航菜单有关信息不能为空。
开发人员导航子菜单管理用例：
与主菜单管理用例类似，开发人员对导航子菜单的操作使用本用例。
在添加子菜单时必须选择一种主菜单项名称和一种导航父菜单项名称。
只有这样才能确定一个导航子菜单项。
子菜单的信息不能为空，相应属性的填写也需要符合各属性要求。
如,坐标属性值必须为数字等。
（二）系统分析
在需求分析的基础上可以进行系统分析，系统分析主要是对系统数据库的分析，包括系统数据库中确定各实体及实体间关系。
数据库系统E-R图如图3-3。
图3-3系统E-R图
根据需求分析，规划出系统数据库中的实体有操作员（即用户）、权限角色、权限关系、主菜单、导航菜单、导航子菜单。
其结构如下：
操作员：
Id号，账户名，密码，权限列表，激活状态。
权限角色：
Id号，角色名，权限列表。
权限关系：
Id号，操作员Id号，权限角色Id号。
主菜单：
Id号，名称，文本，是否根节点，父节点。
导航菜单：
Id号，名称，文本，图片，宽度，高度，X轴位置，Y轴位置。
导航子菜单：
Id号，名称，文本，图片，宽度，高度，X轴位置，Y轴位置，父菜单文本。
系统数据库E-R图中有四个联系类型，其中有两个1：
1联系，两个1：
N联系。
（三）系统分层结构
本系统采用的是B/S三层架构，包括表示层，业务逻辑层，数据访问层。
本系统三层结构模式如图4-4,从左到右为自顶向下。
图3-4系统三层结构模式图
（1）系统表示层
表示层是用户与系统的接口层，用户通过此层的设计实现用户与系统的交互。
它利用友好界面显示数据和接收用户输入的数据，为用户提供一种可视化的交互操作界面。
本系统中项目“CommonMenuModule”含有所有与界面有关的类及其代码，作为表示层。
（2）系统业务逻辑层
处于表示层与数据访问层之间，它在三层架构中起到承上启下的作用。
整个软件有关逻辑设计的代码都要在此层实现。
本系统中项目“IBLL”和项目“BLL”分别含有与业务逻辑相关的接口和类，作为业务逻辑层。
（3）系统数据访问层
数据访问层主要负责数据库的访问，即对数据库中表的SELECT，INSERT，UPDATE，DELETE等的操作。
本系统中项目“IDAL”和项目“DAL”分别含有与数据访问相关的接口和类，作为数据访问层。
四、系统设计
（一）系统数据库设计
对系统数据库的设计主要是对数据库中表和表之间关系的设计。
（1）数据库表的设计
①操作员表结构，如表1所示。
表1Operator（操作员）表结构
字段名
类型
描述
Id
int
操作员Id号
OperatorName
nvarchar（50）
操作员姓名
Password
nvarchar（50）
操作员密码
PurviewList
varbinary（MAX）
权限列表
State
bit
操作员状态
②权限角色表结构，如表2所示。
表2PurviewGroup（权限角色）表结构
字段名
类型
描述
Id
int
角色Id号
GroupName
nvarchar（50）
角色名
GroupPurviewList
nvarchar（50）
权限列表
③权限关系表结构，如表3所示。
表3PurviewRelation（权限关系）表结构
字段名
类型
描述
Id
int
权限关系Id号
OperatorId
int
操作员Id号
PurviewGroupId
int
角色Id号
④主菜单表结构，如表4所示。
表4Menu（主菜单）表结构
字段名
类型
描述
MenuID
int
主菜单Id号
MenuName
varchar（50）
主菜单名称
MenuText
varchar（50）
主菜单文本
PID
int
父节点
RootID
int
根节点
⑤导航菜单表结构，如表5所示。
表5Menu（导航菜单）表结构
字段名
类型
描述
LeftMenuID
int
导航菜单Id号
LeftMenuName
varchar（50）
导航菜单名称
LeftMenuText
varchar（50）
导航菜单文本
续表5Menu（导航菜单）表结构
LeftMenuImg
varchar（200）
图片地址
LeftMenuX
int
X轴位置
LeftMenuY
int
Y轴位置
LeftMenuW
int
宽度
LeftMenuH
int
高度
⑥导航子菜单表结构，如表6所示。
表6Menu（导航子菜单）表结构
字段名
类型
描述
RightMenuID
int
导航子菜单Id号
RightMenuName
varchar（50）
导航子菜单名称
RightMenuText
varchar（50）
导航子菜单文本
RightMenuImg
varchar（200）
图片地址
RightMenuX
int
X轴位置
RightMenuY
int
Y轴位置
RightMenuW
int
宽度
RightMenuH
int
高度
LeftMenuText
varchar（50）
导航菜单名称（父菜单）
（2）数据库表之间关系的设计
图5表PurviewRelation、Operator、PurviewGroup关系图
图5中“PurviewRelation”为权限关系表及其字段，“Operator”为操作员表及其字段，“PurviewGroup”为权限角色表及其字段。
操作员表和权限关系表：
一对一关系，一个操作员只对应一个权限关系，也就是说一个操作员只对应一种角色的权限。
其中PurviewRelation表中字段OperatorId是Operator表中的主键Id，OperatorId字段是表PurviewRelation的外键。
权限角色表和权限关系表：
一对一关系，一种权限角色只对应一种权限关系，即一个权限关系只对应一种角色。
其中PurviewRelation表中字段PurviewGroupId是PurviewGroup表中的主键Id，PurviewGroupId是表PurviewRelation的外键。
在这两种表间的对应关系中，通过PurviewRelation表把Operator表和PurviewGroup表联系起来。
在Operator表中，每行记录都有字段PurviewList以二进制方式存储所对应于本行Id的菜单项权限数据。
在PurviewGroup表中，每行记录都有字段GroupPurviewList以二进制方式存储所对应于本行Id的菜单项权限数据。
而在表PurviewRelation中，每行记录分别以外键OperatorId和外键PurviewGroupId存储着Operator表中的Id字段和PurviewGroup表中的Id字段。
这样便可以利用权限关系来联系各个用户账户与角色的对应关系，从而实现用户菜单项权限按角色分配。
图6表Menu、LeftMenu、RightMenu结构图
图6中“Menu”为主菜单表及其字段，“LeftMenu”导航菜单表及其字段，“RightMenu”为导航子菜单表及其字段。
主菜单表和导航子菜单表：
二者之间没有使用键来联系，但导航子菜单中各个项的数据都是源自主菜单中各项，这在系统功能上需要实现，即添加导航子菜单时菜单项名称的信息是从主菜单项中选择其一得到的。
这样做是因为通常主菜单具有系统所有功能的导航，而导航子菜单为部分已被导航菜单分类的功能导航，所以它一定是属于主菜单的。
导航菜单表和导航子菜单表：
二者之间没有使用键来联系，导航子菜单表（Menu）中字段LeftMenuText的值源自导航菜单表（LeftMenu）的字段LeftMenuText的值，这在系统功能上需要实现，即添加导航子菜单时导航菜单（LeftMenuText）项的信息是从导航菜单项中字段LeftMenuText值选择其一得到的。
而在导航子菜单表字段LeftMenuText的值是可以重复的，他们之间由对应的RightMenuId来区分。
在这两种表间对应关系中，导航菜单把主菜单和导航子菜单联系起来，即导航菜单作为导航子菜单的父项，而导航子菜单项都对应于主菜单项。
虽然二者间有联系，但互不干涉，互不影响。
需要重点说明的是在操作员表（Operator）和权限角色表（PurviewGroup）中分别含有字段PurviewList和字段GroupPurviewList，并且都以二进制数据类型来存储。
其内部信息为所有主菜单项信息及每个菜单项所对应的权限状态信息。
通过这种形式可以在程序中以集合方式提取出来，并在程序中逐个验证每个菜单项的权限状态，实现为用户分配菜单项权限这一主要功能。
并且将权限数据信息分别存储在操作员表（Operator）和权限角色表（PurviewGroup）的PurviewList字段和GroupPurviewList字段中，有利于将用户权限模式和角色权限模式分开，达到可以自由选择权限模式的功能。
（二）系统流程图设计
流程图是反映系统流程最直观的方法，在具体实现程序前必须对系统的流程进行设计，这样可以使整个系统在后续的实现过程中清晰且有条理。
本系统流程图如图7。
图4-1系统流程图
五、系统实现
（一）系统数据库实现
数据库的实现即建立系统所需数据库和表。
建立数据库和表使用的是SQL语言，虽然数据库管理系统有很多，但是建立库、表、存储过程等使用的语言都是基于SQL语言的，只是语法上存在略微不同。
首先建立一个名为“CommonMenuModule”的数据库，此数据库的容量基础为2MB，以1MB为单位增加。
建立表Menu。
Menu表负责存储所有主菜单项及其关系信息。
建立表LeftMenu。
LeftMenu表负责存储所有导航菜单项信息。
建立表RightMenu。
RightMenu表负责存储所有导航子菜单项信息。
建立表Operator。
Operator表负责存储所有用户（操作员）及其对应的菜单项权限信息。
建立表PurviewGroup。
PurviewGroup表负责存储所有角色及其对应的菜单项权限信息。
建立表PurviewRelation。
PurviewRelation表负责存储用户帐户与所对应角色的信息。
（二）系统程序实现
系统程序实现是对系统程序所涉及的所有类和接口等的具体实现。
本系统采用三层架构模式来组织程序，整个系统分为表示层、业务逻辑层和数据库访问层。
（1）表示层实现
表示层主要以窗体、控件来构建友好界面，以事件驱动来组织程序调用流程。
表示层结构如图5-1。
图5-1系统表示层类分布图
Program静态类：
本类中含有Main（）方法，它是应用程序的默认入口方法，负责进行需要完成的启动处理。
Main（）方法中调用Application静态类中的Run（）方法，它负责启动标准的应用程序消息循环。
Resources类：
资源类，用于查找本地化字符串等。
MenuService类：
菜单界面管理类。
实现将主菜单、导航菜单以及导航子菜单的信息绑定到相应的数据显示控件上。
MenuPurviewService类：
菜单权限界面管理类。
实现将账户信息，用户或角色菜单权限信息绑定到相应的数据显示控件或树形视图控件上。
MenuPurviewDataService类：
菜单权限数据管理类。
实现对权限菜单数据的读取和加载。
formLogin类：
用户登录窗体类。
提供用户通过账户名和密码登录系统的界面以及有关事件。
formMain类：
系统主界面窗体类。
提供所有功能操作的界面及有关事件。
formUserPurview类：
用户权限模式管理窗体类。
实现新建和删除用户账户，修改账户信息；为选定账户分配菜单权限，修改菜单项信息等功能的界面和事件。
formGroupPurview类：
角色权限模式管理窗体类。
实现新建和删除角色，修改角色信息；为选定角色分配菜单权限，修改菜单项信息；添加权限关系，为账户分配角色等功能的界面和事件。
formAddPurviewRelation类：
添加角色关系窗体类。
提供选择账户和角色对应关系的界面和事件。
formMenu类：
菜单管理窗体类。
提供管理所有菜单项的界面和事件。
formAddMenu类：
添加主菜单窗体类。
实现添加主菜单项的界面和事件。
formAddLeftMenu类：
添加导航菜单窗体类。
实现添加导航菜单项的界面和事件。
formAddRightMenu类：
添加导航子菜单窗体类。
实现添加导航子菜单项的界面和事件。
formModifyMenu类：
修改主菜单窗体类。
实现修改主菜单项的界面和事件。
formModifyRightMenu类：
修改导航子菜单窗体类。
实现修改导航子菜单项的界面和事件。
formModifyPassword类：
修改用户密码窗体类。
实现修改用户密码的界面和事件。
formAboutMe类：
关于信息窗体类。
实现关于信息的界面和事件。
formLockedScreen类：
锁定屏幕窗体类。
实现锁定屏幕功能的界面和事件。
（2）业务逻辑层实现
业务逻辑层通过定义业务逻辑接口并实现接口，组织为可管理易维护的业务逻辑接口和实现类文件相对应的程序结构。
业务逻辑层结构图如图9。
图5-2系统业务逻辑层类分布图
IOperatorService接口：
操作员业务逻辑接口。
定义与用户（操作员）有关的查询、添加、修改、删除等功能的接口。
OperatorService类：
操作员业务逻辑接口实现类。
实现IOperatorService定义的所有接口。
IPurviewGroupService接口：
角色业务逻辑接口。
定义与角色有关的查询、添加、修改、删除等功能的接口。
PurviewGroupService类：
角色业务逻辑接口实现类。
实现IPurviewGroupService定义的所有接口。
IPurviewRelationService接口：
权限关系业务逻辑接口。
定义与权限关系有关的信息查询、添加、修改、删除等功能的接口。
Purv
升级会员 