代理模式及其在spring与struts2中的体现

代理模式

代理模式有三个角色组成：

　　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中重复配置该拦截器，可以将该拦截器配置成一个默认拦截器栈。