AOP下的权限控制实现

核心提示：摘要 面向方面的编程(AOP)是一种新的编程技术，它弥补了面向对象的编程(OOP)在跨越模块行为上的不足，AOP下的权限控制实现，AOP引进了aspect，它将影响多个类的行为封装到一个可重用模块中，扩展修改难度大，权限控制的J2EE容器实现在AOP概念没有诞生前，它答应程序员对横切关注点进行模块化，从而消除了OOP引

摘要 面向方面的编程(AOP)是一种新的编程技术，它弥补了面向对象的编程(OOP)在跨越模块行为上的不足。AOP引进了aspect，它将影响多个类的行为封装到一个可重用模块中，它答应程序员对横切关注点进行模块化，从而消除了OOP引起的代码混乱和分散问题，增强了系统的可维护性和代码的重用性。本文分析传统权限控制的实现方法，并研究了在AOP下权限控制的实现方法。

　　要害词 AOP；横切关注点； 设计模式； 权限控制

　　OOP应用开发面临的问题

　　面向对象技术很好地解决了软件系统中角色划分的问题。借助于面向对象的分析、设计和实现技术，开发者可以将问题领域的“名词”转换成软件系统中的对象，从而很自然地完成从问题到软件的转换。

　　但是，问题领域的某些需求却偏偏不是用这样的“名词”来描述的。比如碰到这样的问题：需要对系统中的某些方法进行权限检验，这种需要权限检验的方法散布在40多个类中。面对这种需求，应该怎么办呢？最直接的办法就是：创建一个起类（或接口），将权限检验的功能放在其中，并让所有需要权限检验的类继续这个起类（或接口）．假如这个需求是后期提出的．需要修改的地方就会分散在40多个文件中。这样大的修改量，无疑会增加出错的几率，并且加大系统维护的难度。

　　人们熟悉到，传统的程序经常表现出一些不能自然地适合单个程序模块或者几个紧密相关的程序模块的行为例如权限检验、日志记录、对上下文敏感的错误处理、性能优化以及设计模式等等、我们将这种行为称为“横切关注点（crosscuttingconcern）”，因为它跨越了给定编程模型中的典型职责界限。假如使用过用于横切关注点的代码，您就会知道缺乏模块性所带来的问题。因为横切行为的实现是分散的，开发人员发现这种行为难以作逻辑思维、实现和更改。

　　AOP的基本思想

　　AOP是Aspect Oriented PRogramming的缩写，意思是面向方面编程，一种新兴的编程技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。它可以解决OOP和过程化方法不能够很好解决的横切（crosscut）问题，如：事务、安全、日志等横切关注。当未来系统变得越来越复杂，横切关注点就成为一个大问题的时候，AOP就可以很轻松的解决横切关注点这个问题。


图 1 把模块作为一批关注点来实现
　　通常，为满足整个企业应用某方面得需求，开发者（架构师）需要整理出系统得关注点。图 1形象地描述了关注点，它能够从AOP Aspect角度看待系统。比如，持久化、日志、应用的业务逻辑通常被认为是应用需要解决的问题。因此，他们通常作为关注点看待。从整个系统角度考虑，它往往是由大量的关注点构成的。

　　我们把AOP看作是OOP的延续，而不是竞争对手。OOP在通常的场合下工作得很好，但在特定的领域里却有所欠缺：举例来说，假如我们必须为多个对象和方法应用相同的事务行为，我们需要将同样的代码剪切/粘贴到每一个方法里。AOP让我们可以把这类问题封装到方面（aspect）中，从而更好地实现模块化。AOP定义了“切入点”（pointcut）的概念，让开发者可以从另一个角度来思考程序的结构，从而弥补了OOP的某些缺陷：假如需要对一组方法施加横切的行为，就应该拦截这些方法。

　　在J2EE应用开发中，我们主要用到AOP的拦截（interception）能力，它为我们提供了“在任何对象的方法调用前/后加入自定义行为”的能力，这使得我们可以处理企业应用中的横切（crosscutting）关注点（即：同时作用于多个对象的关注点），并且仍然保持强类型（不需要改变方法签名）。

　　权限控制的应用程序实现

　　对于权限治理的做法，在WEB实现上，有以下几种：

　　⑴ 利用Filter，对所有进入的URI进行解析，并取得当时session中的User信息，然后通过RBAC的机制，将此链接需要的权限与用户拥有的权限进行比较，然后进行相应的处理。这种做法有很多好处：简单，轻易实现，并且对系统侵入性也不强。这里URL就是RBAC中的资源了。这样做的缺点是所有对数据的操作必须通过URL来体现，这一点在现代的程序中不太好实现。假如采用Struts, XWork或者Tapestry，采用同一个URL（浏览器看来）进行处理多项任务已不是什么稀奇的事。

　　⑵ 利用一个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();
　}
}
　　这种做法能够将权限的粒度控制到具体的业务方法，因此它的控制能力应该是强大的。可以看到，权限判定部分对于每个方法几乎是独立的。

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

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

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

　　权限控制的J2EE容器实现

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