小圣空间

先前对DispatchAction不了解，今天查了一些资料，供自己学习参考
来源：http://www.jdon.com/jive/article.jsp?forum=16&thread=19673

1) DispatchAction就是在struts-config中用parameter参数配置一个表单字段名,这个字段的值就是最终替代execute被调用的方法. 例如parameter="method"而request.getParameter("method")="save"，其中"save"就是MethodName。struts的请求将根据parameter被分发到"save"或者"edit"或者什么。但是有一点，save()或者edit()等方法的声明和execute必须一模一样。

2) LookupDispatchAction继承DispatchAction, 用于对同一个页面上的多个submit按钮进行不同的响应。其原理是，首先用MessageResource将按钮的文本和ResKey相关联，例如button.save=保存；然后再复写getKeyMethodMap(), 将ResKey和MethodName对应起来, 例如map.put("button.save", "save"); 其配置方法和DispatchAction是一样的, 使用时要这么写:
<html:submit property="method">
<bean:message key="button.save"/>
</html:submit>

3) MappingDispatchAction是1.2新加的, 也继承自DispatchAction. 它实现的功能和上面两个区别较大, 是通过struts-config.xml将多个action-mapping映射到同一个Action类的不同方法上, 典型的配置就是:
<action-mappings>
<action path="/saveUser" type="logic.UserAction" parameter="save"></action>
<action path="/editUser" type="logic.UserAction" parameter="edit"></action>
</action-mappings>
然后UserAction继承MappingDispatchAction，其中有：
public ActionForward save(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception
public ActionForward edit(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception
等方法

可以看到, 不管怎么变化, 其实这些类都是把execute给分解开, 不管是save, edit还是其他什么方法, 其实都是和原来的execute是等价的, save和edit之间没有任何直接的关系, 而事实呢，它们是同一个业务模型的两种不同操作。 我觉得这就是一个问题，对于save和edit这两种请求, 我后台逻辑有可能只是调用service的方法那一句不一样，其他代码是完全一致的(例如错误处理, 日志记录等)。因此我想出了这个小东西，在execute方法内部进行局部分解.上面有人说看iBATIS的代码看到过类似的。的确，iBATIS实现了一个BeanAction，将ActionForm和Acion写到了一个类里，然后通过一个ThreadLocal的局部变量在各个方法之间传递actionMapping, request, response这些参数。其每个方法的声明变得非常简单，返回的也是字符串forward名。

我在很大程度上是受了Clinton Begin的一些启发，但是BeanAction实现的框架稍微有些大，改写了struts的根本模式。而且作者也说，该框架没有经过实际应用的测试，所以我不想用。

楼顶的帖子我?必须用spring的代理，感觉不是很稳定而且大大增加了配置工作。
有人说xxxDao是局部变量，线性不安全。我也是想问问这个，象这种DAO和Service类，其本身一旦建立，是不会进行任何修改的（但是因为要从spring取，所以不能声明为final）。是不是可以理解为提供一些静态方法(例如saveWorld)的工具类呢？这样的话，是不是就不存在线程不安全的问题了？
究竟啥是线性不安全啊！！


下面是使用这个框架的例子。为了简便，去掉了接口层。BaseAction就不写了


===================== TestDAO，真正的业务逻辑实现 =============================
public class TestDAO {
public void editWorld() {
System.out.println("Editing the world");
}

public void saveWorld() {
System.out.println("Saving the world");
}
}

===================== TestService 业务逻辑的facade, 通过spring将testDao注入 =============================
public class TestService {
private TestDAO testDao;

public void setTestDao(TestDAO testDao) { this.testDao = testDao; }

public void editWorldTest() {
testDao.editWorld();
}

public void saveWorldTest() {
testDao.saveWorld();
}
}

===================== TestAction =============================
public class TestAction extends BaseAction {

private TestService getTestService() { return (TestService) getBean("testService"); };

public ActionForward execute(ActionMapping mapping, ActionForm actionForm, HttpServletRequest request, HttpServletResponse response) throws Exception {
TestActionForm form = (TestActionForm) actionForm;
ActionErrors errors = new ActionErrors();

Object[] params={form, request, errors};
// 上面是关键！Object[]不能设置为对象，因为有可能Test2Action的这一行是{form,request,response,messages,context}。这是这个框架灵活性的体现
String forward = dispatchSubAction(form.getMethod(), params, methods);
// 通过method进行分发, 可以采用其他任何变量

saveErrors(request, errors);
return mapping.findForward(forward);
}

//edit,save等方法的参数要和上面的Object[]相对照
public String edit(TestActionForm form, HttpServletRequest request, ActionErrors errors) {
log.info("现在是在edit子动作中");
getTestService().editWorldTest();
return "edit";
}

public String save(TestActionForm form, HttpServletRequest request, ActionErrors errors) {
log.info("现在是在save子动作中");
getTestService().saveWorldTest();
return "save";
}
}