⑵ 利用一个BaseServlet(Servlet+Jsp经典模式)或者BaseAction(Struts模式)或者BasePage(Tapestry模式)或者BaseController(SpringMVC模式)，对所有的请求先进行过滤进行权限操作，然后再处理。稍微看一下就知道这种模式跟Filter并无本质不同。优缺点同上。

那么，如果要实现更为细致的权限操作，精确到某个方法的权限，典型的做法如下：

public someFunciton() { 　 //权限判断 　 User user = context.getUser(); 　 if (user.canExecuteThisFunction()) { 　　 // do the business method 　　 // ... 　 } else { 　　 throw new PermissionDeniedException(); 　 } }

AOP下的权限控制实现(2)

这种做法能够将权限的粒度控制到具体的业务方法，因此它的控制能力应该是强大的。可以看到，权限判断部分对于每个方法几乎是独立的。

这种在具体功能前加入权限操作检验的实现方式有很多缺点：

⑴ 每个功能类都需要相应的权限检验代码，将程序功能和权限检验混淆在一起，存在紧密的耦合性，扩展修改难度大。

⑵ 以代理模式为每个功能类实现一个相应的代理类，虽然解耦了程序功能和权限检验，但是，从某个角色的权限检验这个切面考虑，涉及具体Proxy类太多，扩展修改难度大。

权限控制的J2EE容器实现

在AOP概念没有诞生前，J2EE规范已经提供了关于权限控制的容器实现标准，这种变迁结果如下图所示：

图2 权限控制的J2EE容器实现

原来需要每个应用程序实现的权限Proxy转为整个容器的Proxy实现，其中JDK1.3以后的动态代理API为这种转换实现提供了技术保证。

非常明显，通过容器实现权限控制验证可以大大简化应用程序的设计，分离了应用系统的权限关注，将权限控制变成了对J2EE容器服务器的配置工作。

其实，容器的权限实现也是一种从一个侧面来解决问题方式，AOP概念诞生后，权限控制实现由此也带来了两个方向的变化：

⑴　J2EE容器级别的权限实现，也就是容器自身的权限实现。

⑵　J2EE应用程序级别的权限实现。

权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性，其实象JBoss 4.0这样的J2EE容器，由于引入了AOP概念，使得J2EE开发者在自己的应用系统中能够直接操纵容器的一些行为。容器和应用系统由于AOP引入的Aspect切面，变得可以成为一体了。

对于J2EE应用系统开发者，能够做到上述境界，必须的条件是对JBoss之类J2EE容器必须有足够的了解，因为这些方式并不是J2EE标准，有可能在移植到新的J2EE容器，这些知识和投入变得无用（也有可能将来J2EE扩展其标准）。

很显然，使用AOP实现J2EE应用系统级别的权限控制，是解决上述移植风险的一个主要方法，但是带来的缺点是必须亲自从零开始做起，耗费时间不会很短。

AOP下的权限控制实现

有了AOP，新的业务方法可以这样写：

public someFunciton() { 　 // do the business method 　 // ... }

AOP下的权限控制实现(3)

没有了额外的权限操作，这个业务方法看起来那么清晰自然。

将对权限的操作作为一个Advice，并将Advisor关注到所有的业务方法（可能有某一个特定package），然后，剩下的事情就由RBAC以及AOP来完成了。通过这样的分离，纵向的一个业务方法被分割为一个更为自然的业务方法和一个关注点。这个关注点写法可能如下：

public class PermissionCheckAdvice implements MethodBeforeAdvice { 　 public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable { 　　 //权限判断 　　 if (!this.getContext().getUser().canExcute(th

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!