应用框架的设计与实现——.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不一致会不会产生错误？

权限属性类：



权限判断类：



权限提供者接口定义：



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