应用框架的设计与实现——.NET平台(10 授权服务.源码分析)

设计目标：
SAF.Authorization的目标之一是把权限设置从应用代码中分离出来，从而在无须修改和重新编译应用代码的情况下，就可以改变类和方法的访问权限信息。

实现方式：
1.在方法和类上使用SAFSecurity特性，并以一个不重复的字符串作为名称；
[SAFSecurity(SecurityAction.Demand, Name="NameSpace.Class1.Method1")]

2.在配置文件中定义用户角色和方法、类的访问关系，并指定授权对象；

..............
< Framework  type ="SAF.Configuration.ConfigurationManager,SAF.Configuration" >
     < SAF .Authorization >
         < Providers >
             < Provider  name ="Generic"  type ="SAF.Authorization.GenericAuthorizationProvider,SAF.Authorization,Version=1.0.0.0, Culture=neutral, PublicKeyToken=b638212fecba0404"   />
             < Provider  name ="Windows"  type ="SAF.Authorization.WindowsAuthorizationProvider,SAF.Authorization,Version=1.0.0.0, Culture=neutral, PublicKeyToken=b638212fecba0404"   />
         </ Providers >
         < Permissions >
             < Allows >
                 < Allow  name ="MyAssembly.MyType.MyMethod1"  roles ="BUILTINAdministrators,Managers"  provider ="Windows"   />
             </ Allows >
             < Denies >
                 < Deny  name ="MyAssembly.MyType.MyMethod2"  roles ="BUILTINAdministrators"  provider ="Windows"   />
             </ Denies >
             < Denies >
                 < Deny  name ="MyAssembly.MyType.MyMethod3"  roles ="Anoymous"  provider ="Generic"   />
             </ Denies >
         </ Permissions >
     </ SAF.Authorization >
</ Framework >
..............

3.程序运行时授权对象验证当前用户的角色是否有访问权限；
编译时编译器将SAFSecurity特性对象作为安全特性对象存入元数据，运行期间调用安全特性对象的CreatePermission()方法取得一个IPermission对象－－就是SAFSecurityPermission，调用其Demand()方法验证用户权限；
在书作者的实现中此时将验证的大任交给IAuthorizationProvider的一个对象来承担，对象是使用配置信息来构建的，此时就实现了权限逻辑从框架代码中分离的效果，权限验证类用户可自定义；


问题：
配置文件中每一个方法的可访问和不可访问定义中都有一个provider属性，如果一个方法在Allows组中定义的provider和Denies组中定义的provider不一致会不会产生错误？

权限属性类：



权限判断类：



权限提供者接口定义：



书作者实现的两个权限提供者类之一：