代理模式
代理模式有三个角色组成：
1．抽象主题角色：声明了真实主题和代理主题的共同接口。
2．代理主题角色：内部包含对真实主题的引用，并且提供和真实主题角色相同的接口。
3．真实主题角色：定义真实的对象。
我们先来看传统方式下一个Proxy的实现实例。
假设我们有一个UserDAO接口及其实现类UserDAOImp:
UserDAO.java:
|
public interface UserDAO { public void saveUser(User user); } |
UserDAOImp.java:
|
public class UserDAOImp implements UserDAO{ public void saveUser(User user) { …… } } |
如果我们希望在UserDAOImp.saveUser方法执行前后追加一些处理过程，如启动/
提交事务，而不影响外部代码的调用逻辑，那么，增加一个Proxy类是个不错的选择：
UserDAOProxy.java
|
public class UserDAOProxy implements UserDAO { private UserDAO userDAO; public UserDAOProxy(UserDAO userDAO) { this.userDAO = userDAO; } public void saveUser(User user) { UserTransaction tx = null; try { tx = (UserTransaction) ( new InitialContext().lookup("java/tx") ); userDAO.saveUser(user); tx.commit(); } catch (Exception ex) { if (null!=tx){ try { tx.rollback(); }catch(Exception e) { } } } } } |
UserDAOProxy同样是UserDAO接口的实现，对于调用者而言，saveUser方法的使
用完全相同，不同的是内部实现机制已经发生了一些变化――我们在UserDAOProxy中为
UserDAO.saveUser方法套上了一个JTA事务管理的外壳。
上面是静态Proxy模式的一个典型实现。
现在假设系统中有20个类似的接口，针对每个接口实现一个Proxy，实在是个繁琐无
味的苦力工程。
动态代理
Dynamic Proxy的出现，为这个问题提供了一个更加聪明的解决方案。
我们来看看怎样通过Dynamic Proxy解决上面的问题：
|
public class TxHandler implements InvocationHandler { private Object originalObject; public Object bind(Object obj) { this.originalObject = obj; return Proxy.newProxyInstance( obj.getClass().getClassLoader(), obj.getClass().getInterfaces(), this); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result = null; if (!method.getName().startsWith("save")) { UserTransaction tx = null; try { tx = (UserTransaction) ( new InitialContext().lookup("java/tx") ); result = method.invoke(originalObject, args); tx.commit(); } catch (Exception ex) { if (null != tx) { try { tx.rollback(); } catch (Exception e) { } } } } else { result = method.invoke(originalObject, args); } return result; } } |
首先注意到，上面这段代码中，并没有出现与具体应用层相关的接口或者类引用。也就
是说，这个代理类适用于所有接口的实现。
其中的关键在两个部分：
1.
|
return Proxy.newProxyInstance( obj.getClass().getClassLoader(), obj.getClass().getInterfaces(), this); |
java.lang.reflect.Proxy.newProxyInstance方法根据传入的接口类型
（obj.getClass().getInterfaces()） 动态构造一个代理类实例返回， 这个代理类是JVM
在内存中动态构造的动态类，它实现了传入的接口列表中所包含的所有接口。
2
|
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { …… result = method.invoke(originalObject, args); …… return result; } |
InvocationHandler.invoke方法将在被代理类的方法被调用之前触发。通过这个方
法中，我们可以在被代理类方法调用的前后进行一些处理，如代码中所示，
InvocationHandler.invoke方法的参数中传递了当前被调用的方法（Method） ，以及被
调用方法的参数。
同时，我们可以通过Method.invoke方法调用被代理类的原始方法实现。这样，我们
就可以在被代理类的方法调用前后大做文章。
在示例代码中，我们为所有名称以“save”开头的方法追加了JTA事务管理。
Spring中AOP实现
其中最典型的就是Spring中的配置化事务管理，先看一个例子
|
<beans> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName"> <value>org.gjt.mm.mysql.Driver</value> </property> <property name="url"> <value>jdbc:mysql://localhost/sample</value> </property> <property name="username"> <value>user</value> </property> <property name="password"> <value>mypass</value> </property> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource"> <ref local="dataSource" /> </property> </bean> <bean id="userDAO" class="net.xiaxin.dao.UserDAO"> <property name="dataSource"> <ref local="dataSource" /> </property> </bean> <bean id="userDAOProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"> <ref bean="transactionManager" /> </property> <property name="target"> <ref local="userDAO" /> </property> <property name="transactionAttributes"> <props> <prop key="insert*">PROPAGATION_REQUIRED</prop> <prop key="get*"> PROPAGATION_REQUIRED,readOnly </prop> </props> </property> </bean> </beans> |
看看例子当中的userDAOProxy，想必大家已经猜测到Spring事务管理机制的实现原理。
是的，只需通过一个Dynamic Proxy对所有需要事务管理的Bean进行加载，并根据配
置，在invoke方法中对当前调用的方法名进行判定，并为其加上合适的事务管理代码，那
么就实现了Spring式的事务管理。
当然，Spring中的AOP实现更为复杂和灵活，不过基本原理一致。
Stuts2中的AOP实现
拦截器是Strut2的一个重要组成部分，对于Strut2框架而言，可以将其理解为一个空的容器，正是大量的内建拦截器完成该框架的大部分操作。比如，params拦截器将http请求中的参数解析出来，设置成action的属性；servlet-config直接将http请求中的httpServletRequest实例和httpServletRespon实例传给action；fileUpload拦截器负责解析请求当中的文件域，并将文件域设置为action的属性。。。。。。
对于Strut2的拦截器体系而言，当我们需要某个拦截器的时候，只需要在配置文件中应用该拦截器即可，反之亦然。不管是否应用某个拦截器，对于整个Strut2框架都不会影响，这种设计哲学，是一种可插拔的设计，具有非常好的可扩展性。
Strut2中的拦截器体系是一种AOP设计哲学，它允许开发人员以一种简单的方式来进行AOP方式的开发。
下面以一个例子来介绍Strut2中的AOP。
使用拦截器完成权限控制
l 实现拦截器
大部分web应用都涉及权限控制，当浏览者需要执行某个操作时，应用需要先检查浏览者是否登录，以及是否有足够的权限来执行该操作。
本示例要求用户登录，必须为制定用户名才可以查看系统中某个视图资源，否则直接转入登录页面。对于上面的需求，可以在每个action执行业务逻辑之前，先执行权限检查逻辑，但这种做法不利于代码复用。因为大部分action中检查权限代码都大同小异，故将这些代码逻辑放在拦截器中，将会更加优雅。
检查用户是否登录，通常都是跟踪用户的Session来完成的，通过ActionContext即可访问到Session中的属性，拦截器的intercep(ActionInvocation invocation)方法的invocation参数可以很轻易的访问到请求相关的ActionContex实例。
|
//权限检查拦截器继承AbstractIntercept Public class AuthorityInterceptor extends AbstractInterceptor{ //拦截action处理的拦截方法 Public String intercept(ActionInvocation invocation){ //取得请求相关的ActionContex实例 ActionContext ctx = invocation.getInvocationContext(); Map session = ctx.getSession(); //取出名为user的session属性 String user = (String)session.get(“User”); If(user !=null && user.equals(“scott”) ){ Return invocation.invoke(); } Ctx.put(“tip”,”您还没有登录，请输入scott、tiger登录”); Return Action.Login; } |
上面的拦截器代码非常简单，先从ActionInvocation 取得用户的session实例，然后从中取出user属性，通过判断属性值确定用户是否登录，从而判断是否转入登录页面。
l 配置拦截器
一旦实现了拦截器，就可以在所有需要实现权限控制的action中复用上面的拦截器。
为了使用拦截器，首先需要在struts.xml文件中定义该拦截器，定义拦截器的配置片段如下：
|
<interceptors> <interceptor name=”authority” class=”qj.AuthorityInterceptor” /> </interceptors> |
定义了拦截器后，可以在action中应用该拦截器，应用拦截器的配置片段如下：
|
<action name=”viewBook”> <result>/WEB-INF/jsp/viewBook.jsp</result> <interceptor-ref name=”defaultStack” /> <interceptor-ref name=”authority” /> </action> |
这种通过拦截器控制权限的方式，显然具有更好的代码复用。
如果为了简化struts.xml文件的配置，避免在每个action中重复配置该拦截器，可以将该拦截器配置成一个默认拦截器栈。