RT   求解

dispatchAction是struct1.x的内容。是action 中的一个子类
最大用途是减少类建立的数目，方便维护。
因为它的出现就是为了解决用一个action处理多个操作

DispatchAction 是struts 1.x里有　
　　在java web开发中，原始的配置action都是使用一个action类实现一个功能，如果工程项目够大，action类数目会很多，就增加了该项目后期的维护难度。解决的方法，这里给大家介绍一个struts包下的action子类，DispatchAction。
　　DispatchAction继承自Action类，它是一个抽象类，封装了一些基础方法，来解决使用一个Action处理多个操作的能力，这就是DispatchAction最大的用途，它可以帮助我们用一个Action类，封装一套类似的操作方法，节省了类的数目，同时也减轻了后期维护的困难。
　　DispatchAction中主要包括以下几个方法：
　　protected ActionForward dispatchMethod
　　protected java.lang.reflect.Method getMethod
　　protected java.lang.String getMethodNameDispatchAction在配置上与标准的Action稍有不同，就是要在Action配置中多一个parameter属性，这个属性将指导DispatchAction找到对应的方法，例如这样配置：
　　<action path="/saveSubscription" type="org.apache.struts.actions.DispatchAction" name="subscriptionForm" scope="request" input="/subscription.jsp" parameter="method"/>
　　parameter的属性值是可以任意起的，只要你记得在传参数的时候统一就可以了。比如我写了一个类似这样的Action，它继承自DispatchAction类，包含了三个操作方法，有Add(),Update(),Delete()。当我想要调用这个Action的Update操作时，提交的URL应该类似这样的：
　　saveSubscription.do?method=Update
　　就是这么简单，不过非常方便我们程序员了，开发中我感觉的确省了好多代码，至少以前的三个类文件变成了现在一个类了，而且在后期维护的时候感觉也是方便很多。
　　需要注意的是：在调用DispatchAction的时候method参数是不能为空的，如果空，DispatchAction会调用unspecified方法并抛出异常。
　　另外一种就是在jsp页面加入一个隐藏域
　　<input type="hidden" name="oparator" value="getFangwuByUid" />
　　然后用表单提交 那么 Struts xml配置文件中就改成
　　<action path="/getFangwu" name="fangwuForm"
　　type="com.zf_sh.action.FangWuAction" parameter="oparator">
　　配置文件中的parameter 值就是jsp页面隐藏域的值
　　其他的和Action的配置没有太大的区别 这里的名字是随便取的

用Struts标签来定义这样的隐含的变量，因为Struts标签为动态标签，它可能需要在FormBean中定义该属性的get和set方法，而在parameter中定义的值不需要在FormBean当中定义get和set方法。笔者建议用html的标准标签<input>来定义该隐藏变量。因为该标签为静态标签，如果我们该用Struts标签的话可能导致页面出错。

相信用过Struts框架的朋友应该都知道有个叫DispatchAction的东西，主要是用来解决因Action过多而导致代码文件膨胀的。
我在此首先假设有个自己写的Action类叫UserAction，并且继承自DispatchAction，同时，在UserAction写了saveUser()、deleteUser()、updateUser()三个方面，在Struts配置文件中对应的parameter参数配置为method，path参数配置为userAction。那么，对应与客户端调用UserAction中相应方法的方式为：

.../userAction.do?method=saveUser

.../userAction.do?method=deleteUser

.../userAction.do?method=updateUser

虽然，相比写三个普通的Action或者在一个Action通过request.getParameter()的方式去实现有一定的好处，但是，同时，也带来了一个问题。万一由于用户误操作修改了method之后的参数方法，且方法并未在UserAction中出现，那么则会抛出名为NoSuchMethodException的异常。下面对于这个问题，提供一些解决该问题的思路。

Java代码 复制代码 收藏代码
1.protected Method getMethod(String name)  
2.           throws NoSuchMethodException {  
3.  
4.       synchronized(methods) {  
5.           Method method = (Method) methods.get(name);  
6.           if (method == null) {  
7.               method = clazz.getMethod(name, types);  
8.               methods.put(name, method);  
9.           }  
10.           return (method);  
11.       }  
12.  
13.   }  


通过阅读DispatchAction的源码，其中里面有这么一段代码，抛出了上述提及的异常，其实，我们可以对DispatchAction这个类进行下改造方可解决问题。



Java代码 复制代码 收藏代码
1.protected Method getMethod(String name)  
2.        {  
3.     synchronized(methods) {  
4.         Method method = (Method) methods.get(name);  
5.         if (method == null) {  
6.             try {  
7.        method = clazz.getMethod(name, types);  
8.    } catch (SecurityException e) {  
9.        e.printStackTrace();  
10.    } catch (NoSuchMethodException e) {  
11.                                    <span style="color: rgb(0, 0, 0);">//当出现异常时，抛出一个自定义的异常，同时跳转错误提示页码，并显示错误信息！</span>  
12.  
13.  
14.  
15.        throw new AppException("操作错误，请检查操作！");  
16.    }  
17.             methods.put(name, method);  
18.         }  
19.         return (method);  
20.     }  
21. }  


通过以上的改造，那么对于method参数，不管它的值怎么修改都不会直接抛出一堆普通用户所看不懂的错误信息了，而是跳转到了相应的错误提示页面，增强了系统的友好性。其实，这个方面也并没什么技术含量，无非就是稍微改造了下源代码。

对于DispatchAction如果参数method省略的话，可以重写它的unspecified()方法