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

时间:2022-01-10 18:06:32

代理模式

代理模式及其在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中重复配置该拦截器,可以将该拦截器配置成一个默认拦截器栈。