Spring MVC 中的 MultiActionController 用法详解

本文详细介绍了SpringMVC中的MultiActionController及其方法名解析器的使用方式,包括InternalPathMethodNameResolver、ParameterMethodNameResolver和PropertiesMethodNameResolver,并通过具体示例展示了如何配置以实现不同的请求映射。
摘要由CSDN通过智能技术生成
Spring MVC 中 Controller 的层次实在是多,有些眼花缭乱了。在单个的基础上,再新加两三个叫做丰富,再多就未必是好事,反而会令人缩手新闻片脚,无从定夺。多数 Controller 都是只完成一个任务,不过也有一个像 Struts 的 DispatchAction 的那样的 Conntroller,org.springframework.web.servlet.mvc.multiaction.MultiActionController,意即在一个 Controller 中处理多个动作,如同一个业务的增、删、改可以放在一起了。不至于增、删、改各自为政,造成代码混乱、重复难以维护。

本文中的 web.xml 的 org.springframework.web.servlet.DispatcherServlet 所处理的 url-pattern 是 *.html,如何搭建 Spring MVC 项目不细加说明,可参考我前面同系列的文章。

例如,下面的 UserController,有两个签名一样的 updateUser() 和 deleteUser() 方法



用过 Struts 的 DispatchAction 的都知道,是通过 http://.../userAction.do?method=updateUser 的方式来指定执行哪个方法。那 Spring MVC中是如何定位到所需方法上呢?

Spring MVC 除了有一个叫做 HandlerMapping(把 URL 解析到 Controller) 的东西,还要把操作进一步解析到方法名上,即要找到的 Controller 上的哪个方法并执行之。缺省的方法名解析器是 InternalPathMethodNameResolver,它根据 URL 样式解析方法名。

在缺省的 BeanNameUrlHandlerMapping 和缺省的 InternalPathMethodNameResolver 协调之下,Bean 上下文可以这样配置:



这样分别通过下面的 URL 就能执行到正确的方法上去了:

http://.../updateUser.html  --  将被 UserController.updateUser() 处理
http://.../deleteUser.html   --   将被 UserController.deleteUser() 处理

但是,你应该注意到了,上面的 com.unmi.UserController 配置了两次,一来碍眼、二来原来只要 Singleton 的 UserController 实例不再是那么回事了。所以要引入 SimpleUrlHandlerMapping 对 Bean 配置进一步紧凑一下:



说是紧凑,倒不如说 Bean 配置复杂了,反正不用配置两个相同的 UserController 实例了。还是通过上面那两个 URL 来访问执行到相应的方法。

除了缺省的方法名解析器 InternalPathMethodNameResolver(注意了,Spring 中缺省的 XXX 很多用 InternalXXX 的命名),还有两种其他类型的方法名解析器:

·ParameterMethodNameResolver -- 根据请求中的参数解析执行方法名,相当于 Struts 的 DispathAction
·PropertiesMethodNameResolver -- 根据查询一个 key/value 列表解析执行方法名,相当于 Struts 的 MappingDispatchAction(用得很少)

下面逐一介绍使用上面两种方法名解析器时的 Bean 配置及相应访问的 URL。

使用 ParameterMethodNameResolver 时的 Bean 配置(为简单起见,又用回了缺省的 HandlerMapping):



这时候分别用下面的 URL 就能访问到相应的方法

http://.../user.html?method=updateUser -- 将被 UserController.updateUser() 处理
http://.../user.html?method=deleteUser  -- 将被 UserController.deleteUser() 处理

通过参数的方式使得 HTML 表单表现用户选择成为可能,例如把 method 参数可放在一个下拉框或隐藏域中。

使用 PropertiesMethodNameResolver 时的 Bean 配置



这种配置有点复杂,PropertiesMethodNameResolver 不仅与 SimpleUrlHandlerMapping 相仿又有重叠,而且必须把 SimpleUrlHandlerMapping  拉进来,无法使用默认的 HandlerMapping。从上面的配置我们可以明显的看出 HandlerMapping 和 MethodNameResolver 不同职责了,一个是定位 Controller,一个是定位 Method。

这时候分别用下面的 URL 来访问到相应 Controller 的方法

http://.../updateUser.html  --  将被 UserController.updateUser() 处理
http://.../deleteUser.html   --   将被 UserController.deleteUser() 处理

这里的 URL 恰巧和使用 InternalPathMethodNameResolver  时是一样的,但一定要理解其实他们的机制是一样的。

PropertiesMethodNameResolver 把事性搞这么复杂,被誉为最复杂的方法名解析器。可我还真看不出它还有什么独到之处,或值得一用的理由,同时也不难理解 Struts 的 MappingDispatchAction 鲜为人知的缘由了。
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值