设计使用MultiActionController心得

今天总结一下在一个Spring的项目中使用MultiActionController的应用小结。
在项目开发过程中，面对一个需要对一个域对象进行查询明细，查询列表和查询该域对象的关联对象的案例，这里不包括对域对象进行更新的工作，这样如果采用实现Controller接口的话，每个实现类执行handleRequest返回ModelAndView来达到目的，很自然的将会产生3个实现类，这样项目的类文件数量增多，而且在以后维护工作中，虽然在一个用例中，仍然不得不从配置文件下手，一个一个根据映射找出对应的相应的Controller，这添加了维护的难度，所以这里我们很自然的采用了MultiActionController做实现。代码基本类似如下：
[code]public class BookMultiController extends MultiActionController{

//(1)
public ModelAndView getBook(HttpServletRequest request,
HttpServletResponse response) {
ModelAndView mv = new ModelAndView("book/book_detail");
Book book = bookManager.getBook(request.getParameter("bookId"));
mv.addObject("book", book);
return mv;
}

//(2)
public ModelAndView getBookList(HttpServletRequest request,
HttpServletResponse response) {
ModelAndView mv = new ModelAndView("book/book_list");
Book book = new Book();
BeanUtils.populate(book, request.getParameterMap());
List list = bookManager.getBooks(book);
mv.addObject("bookList", list);
return mv;
}

//(3)
public ModelAndView getAuthorByBook(HttpServletRequest request,
HttpServletResponse response) {
ModelAndView mv = new ModelAndView("author/author_detail");
Author author = authorManager.getAuthorByBookId(request.getParameter("bookId"));
mv.addObject("author", author);
return mv;
}
}[/code]
在Url配置映射方面，我们使用了org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver，所以上述代码
的访问是：
book.do?method=getBook&bookId=123;
book.do?method=getBookList&bookName=JavaDesign&price=100;
book.do?method=getAuthorByBook&bookId=123;
这样实现下来似乎很不错了。但是在开发过程中，这样情况还会出现很多，当我们碰到一个综合查询的时候，往往会有一颗树，点击树的每一个节点，通过传递一些参数，我们需要看到想要的结果显示在正确的页面。如果采用实现Controller的方法，那么每一个节点的点击将具体的对应到一个相应，通过处理返回ModelAndView。如果考虑这颗树的节点很多，那么是否应该随着节点的不断增加，controller也不断的增加，配置文件的不断增加呢？如果不这样，是否还是考虑使用MultiActionController呢？在这里我们的选择还是使用MultiActionController来实现，不过带来的后果就是有多少个节点，就意味着MultiActionController有多少个对应的方法执行来返回ModelAndView。在这里已经假设节点有很多的情况，那么就意味着这个Controller随着执行方法的增加，代码也会会很冗长。如果有30个节点的话，上面的方法将会有30个，代码一多，这时仔细看看，其实他们都很薄，也都很相似。这里薄和相似是他们
都没有像SimpleFormController那样需要绑定对象，对对象进行验证，保存和更新的动作，他们都是从用户请求那里拿到参数，然后返回给用户希望得到的东西，这就足够了。所以我们在这个基础上加了一些东西，让这些事情做起来更容易一些，在MultiActionController注入了一个IRequestHandler，由它来完成上述的需求，这样30个方法的查询，实现起来至多也就是2个。拿一开始的用例来举例，代码：
[code] public ModelAndView query(HttpServletRequest request,
HttpServletResponse response) {
requestHandler.dynamicInvocate(request);
Solution solution = requestHandler.getSolution();
return new ModelAndView(solution.getPage(),solution.getModelName(),solution.getModel());
}

public ModelAndView queryBook(HttpServletRequest request,
HttpServletResponse response) {
Book book = new Book();
BeanUtils.populate(book, request.getParameterMap());
Map<String,Object> map = new HashMap<String,Object>();
map.put("book", book);
requestHandler.dynamicInvocate(request, map);
Solution solution = requestHandler.getSolution();
return new ModelAndView(solution.getPage(),solution.getModelName(),solution.getModel());
}[/code]
对应的访问变成：
query.do?method=query&purpose=getBook&bookId=123;
query.do?method=queryBook&purpose=getBookList&bookName=JavaDesign&price=100;
query.do?method=query&purpose=getAuthorByBook&bookId=123;
这里IRequestHandler有两个版本的dynamicInvocate，第一个最为简单，就是从请求控制域获取参数然后执行调用，并最终返回一个Solution对象，这里面封装了模型和视图。而第二个版本，则可以实现更多的参数传递的调用。如一开始的代码清单(2)中，是没有办法直接从请求中获取Book对象的，这样构建一个Map传递给调用，也能成功的得到模型和视图。完成了这些，回过头来再次考虑刚才那个拥有30个节点的树，如果足够幸运，所有的查询都是从request，或者session中获取的参数，那么只有一个MultiActionController类文件，并且只有一个方法。值得一提的是这个requestHandler我们是使用方法注入的，也就是他始终是以原型的形式出现，不会造成一些负面的影响，在我们系统测试运行期间，他运作的很好，效果还算满意。
大家对这样的设计有何看法，欢迎大家讨论。