关于权限管理的系统的构思

在 WEB 权限控制里面 多见的方式是于 UI 层进行控制。当用户需要进行某样操作时根据一个 PowerCheck() 的方法检查用户是否拥有该操作。如果有则执行，无则进行弹窗提示。更进一步则是在 Page_Load() 或者用户空间的类似 Init() 这样的初始化函数里面来进行权限控制。如果用户拥有某项权限则显示相应的功能按钮给用户看，无则隐藏之。

 1 // 按钮执行过程中的 
 2 If (PowerCheck(userid,”文章管理”))
 3 {
 4  //执行按钮事件
 5}
 6 Else
 7 {
 8//弹窗警告
 9}
10
11 // 或者
12
13 Page_Load
14 {
15  //判断用户是否拥有该权限。如果拥有则允许用户访问。
16  If (PowerCheck(userid,”新增文章”))
17   btnAddMessage.visable=true;
18   else btnAddMessage.visable=false;
19}
20

 

老式的权限控制的方法其目的在于通过对UI层界面的控制实现业务逻辑中的权限控制。但是缺点在于每次进行权限控制时均需要针对具体权限编码。而且权限控制过于分布，每次修改时会比较繁琐。特别拥有大量且负责的UI界面时极为复杂。

 

在我曾经参与开发过轻型工作流过程中，我发现在工作流中每一条工作流所有的业务逻辑均靠一个剧本来描述。每一次一条工作流的实例化就像一个电影的演出，若干幕情节构成了一个完成的流程。每一幕拥有自己的场景和角色。每个角色根据自己的台词执行不同的任务。更为复杂的是有些幕结束后才会知道下一幕的舞台和角色。然后正是因为有了工作流引擎，它能够非常灵活和强大的控制好每个角色做好自己本分的事情。每一幕就是一个场景，在工作流中往往是一些文件夹，还有表单，资料。每个角色在这个场景中能做什么不能做什么都是经过严格控制的。软件开发的艺术正是在于我们通过软件创作剧本然后让用户角色去扮演我们希望他们成为的角色。

 

在更为自动编码方式繁多的今天。我寻思着是不是模仿工作流引擎做一个权限监督的方法去控制UI界面来实现对业务逻辑的控制。当然如果能对业务逻辑直接控制权限更佳。但是如何让UI及其事件自配置相应的业务逻辑确不易实现。所以本次研究的重点在于如果开发一套更为通用的UI层权限控制方法。

首先 在普通的WEB管理后台中。我们可以把所有不同的后台管理看成不同的流程。每种后台管理同样拥有一个或者多个场景和角色。和工作流不同之处在于，用户环境这里变成了不同的UI界面。我们仅仅需要对每个UI界面的按钮、文本按钮、菜单进行权限控制。就能整体上把握每个用户在场景中能够做什么不能做什么。在ASP.NET里面每个页面均采用控件树的形式来构成。通过搜索树我们很容易判断需要对什么和不对什么进行权限控制。

 

现在看看如果要实现我们需要的权限控制方式,我们需要做些什么。

 

我们需要一个统一的Framework来实现UI层的表现方式。这方面我们可以开发一个基类，该基类继承于WebControl并重构了初始化方法。然后所有的功能我们可以做成用户控件并继承于该基类。我们可以在每个用户登录后在系统中实例化一个该用户的权限剧本。每个用户界面需要显示之前会通过该剧本获取这个用户界面显示的方式。这样的话当需要进行权限控制时，我们只需设置好该用户的权限剧本既可。当然，每个用户控件得知道自己的剧本是什么。工作流中，所以需要针对用户设定的权限均是针对剧本的一个实例来设置的。不同的剧本不同的实例在初始化时指定相应的角色和用户（或者用户组）。在WEB后台中，不同的用户访问一个后台界面我们可以理解为一个流程的实例化。该用户是扮演哪些UI中的角色是需要我们实例化时确定的。这些东西需要用一个方式来存放。我们可以采用二机制的加减法或者Xml文件来完成这样的配置,从而使具体的权限控制从开发中解放出来。每次实例化界面时读取用户的权限配置表即可以知道UI用什么样的方式来组织。这样的话我们每次开发用户控件时仅仅需要做的事情就是继承于该基类。然后在数据库中设置响应的权限配置即可。

转载于:https://www.cnblogs.com/wzyexf/archive/2006/03/30/362691.html