主要原因在于需要在UI层<=>逻辑层<=>数据层之外增加额外的一层来使得AOP拦截可以以恰当的粒度、恰当的时机切入。如果不增加额外的这一层而使用AOP就可能会得到这样的结果--比如,在业务逻辑层或数据层使用AOP切入,就有可能出现这样的情形,用户花了老大的劲将要录入的信息敲入了,最后当点击“提交”时,系统却提示说“你没有权限进行添加操作!”。如果你是这个用户,你一定会郁闷得吐血!
所以,如果系统不允许用户添加,则根本就不应该让添加的Page或Form出现在用户眼前,然而,这在逻辑层或数据层是无法获取这个信息的,只有UI层知道这是发生在什么时刻。但是,在UI层使用AOP截获,你看见过么?我没有,我相信那不是一件容易做的工作。
于是,我开始寻找AOP之外的方法,终于,我找到了一个自己还比较满意的解决方案。下面我们以B/S系统为例,来详细描述这个方案,如果是C/S系统,可以类推之。
为了构建一个在不同B/S系统中可以复用的解决方案,我们需要规范化(定义)一些基础设施或元素。首先,我们需要定义权限的类别,比如最常见的有浏览、添加、修改、删除。你也许已经想到使用一个枚举就可以了。但是,不能使用枚举,因为枚举是sealed,不能被继承,这就意味着权限类别将不能被自定义扩展,所以,我没有使用enum,而是使用class。
/// 应用可以扩展PermissionType,以增加其它权限类别,比如审核等
/// 自定义类别取值应大于 5
/// </summary
public class PermissionType
{
public const int Browse = 1 ;
public const int Add = 2 ;
public const int Update = 3 ;
public const int Delete = 4 ;
}
{
public const int Audit = 10 ; //审核
public const int CancelAudit = 11 ; //消审
}
/// 应用可以扩展IPermission,以增加其它权限类别,比如审核等
/// </summary>
public interface IPermission
{
bool CanBrowse{get ;}
bool CanAdd{get ;}
bool CanUpdate{get ;}
bool CanDelete{get ;}
}


#region GeneralPermission
public class GeneralPermission :IPermission
{
public bool HasNonePermit
{
get
{
return ! (CanBrowse || CanAdd || CanUpdate || CanDelete || CanAudit || CanCancelAudit) ;
}
}
#region IPermission 成员
#region CanBrowse
private bool canBrowse = false ;
public bool CanBrowse
{
get
{
return this.canBrowse ;
}
set
{
this.canBrowse = value ;
}
}
#endregion
#region CanAdd
private bool canAdd = false ;
public bool CanAdd
{
get
{
return this.canAdd ;
}
set
{
this.canAdd = value ;
}
}
#endregion
#region CanUpdate
private bool canUpdate = false ;
public bool CanUpdate
{
get
{
return this.canUpdate ;
}
set
{
this.canUpdate = value ;
}
}
#endregion
#region CanDelete
private bool canDelete = false ;
public bool CanDelete
{
get
{
return this.canDelete ;
}
set
{
this.canDelete = value ;
}
}
#endregion
#region CanAudit
private bool canAudit = false ;
public bool CanAudit
{
get
{
return this.canAudit ;
}
set
{
this.canAudit = value ;
}
}
#endregion
#region CanCancelAudit
private bool