1700484908
1700484909
1700484910
1700484911
图38-6 模型管理器类图
1700484912
1700484913
首先说ActionManager类，它负责管理所有的行为类Action，那就必须定义一个行为类的接口或抽象类，如代码清单38-13所示。
1700484914
1700484915
代码清单38-13 抽象Action
1700484916
1700484917
public abstract class ActionSupport{
1700484918
1700484919
public final static String SUCCESS=“success”；
1700484920
1700484921
public final static String FAIL=“fail”；
1700484922
1700484923
//默认的执行方法
1700484924
1700484925
public String execute（）{
1700484926
1700484927
return SUCCESS；
1700484928
1700484929
}
1700484930
1700484931
}
1700484932
1700484933
抽象的ActionSupport类看起来很简单，其实它可不简单，所有的模型行为都继承该类，它之所以提供一个默认的execute方法，是因为在xml的配置文件中，可以省略掉method=“XXX”这句话，默认就是调用该方法。它还有一个非常重要的行为：对象映射，把HTTP传递过来的字符串映射到一个业务对象上，我们会在值栈中详细讲解。
1700484934
1700484935
读者可能很疑惑，Action的操作是需要获得环境数据的，比如HTTPServletRequest的数据，还有系统中的Session数据，单单一个ActionManager如何获得这些数据呢？通过值栈，在值栈中保存着该Action需要的所有数据。
1700484936
1700484937
我们再来看ActionManager类，如代码清单38-14所示。
1700484938
1700484939
代码清单38-14 Action管理类
1700484940
1700484941
public class ActionManager{
1700484942
1700484943
//执行Action的指定方法
1700484944
1700484945
public String execAction（String actionName）{
1700484946
1700484947
return null；
1700484948
1700484949
}
1700484950
1700484951
}
1700484952
1700484953
就这么简单吗？非也，其中的参数actionName指xml配置中的name属性值，它与从HTTP传递过来的请求对象是一致的，根据HTTP传递过来的actionName在xml文件中查找对应的节点（Node），然后就可以获取到该类的名称和方法，通过动态代理的方式执行该方法，在这里我们使用到了代理模式。
1700484954
1700484955
有读者可能听说过反射是影响性能的，它提供解释型操作。是这样的，但是实际应用还没有这么高的要求，把数据库设计得优秀一点，系统架构多考虑一点，提升的性能远比这个多。
1700484956
1700484957
然后我们再来看拦截器，拦截器和过滤器的区别就是：拦截器可以脱离容器（J2EE容器）运行，而过滤器不行。拦截器的目的是对数据和行为进行过滤，符合条件的才可以执行Action，或者是在Action执行完毕后，调用拦截器进行回收处理。我们定义一个抽象的拦截器，如代码清单38-15所示。