前言
不知这个标题能否勾起你的好奇心和求知欲?在Spring MVC的使用中,若我说@RequestMapping是最为常用的一个注解你应该没啥意见吧。若你细心的话你能发现它有一个name属性(Spring4.1后新增),大概率你从来都没有使用过且鲜有人知。
我本人搜了搜相关文章,也几乎没有一篇文章较为系统化的介绍它。可能有人会说搜不到就代表不重要/不流行嘛,我大部分统一这个观点,但这块知识点我觉得还挺有意思,因此本文就针对性的弥补市面的空白,带你了解name属性的作用和使用。更为重要的是借此去了解学习Spring MVC非常重要的URI Builder模式
@RequestMapping的name属性
首先看此属性在@RequestMapping中的定义:
@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Mapping public @interface RequestMapping { // @since 4.1 String name() default ""; ... }
javadoc描述:为此映射分配名称,它可以使用在类上,也可以标注在方法上。
在分析RequestMappingHandlerMapping源码的时候指出过:它的createRequestMappingInfo()方法会把注解的name封装到RequestMappingInfo.name属性里。因为它既可以在类上又可以在方法上,因此一样的它需要combine,但是它的combine逻辑稍微特殊些,此处展示如下:
RequestMappingInfo: // 此方法来自接口:RequestCondition @Override public RequestMappingInfo combine(RequestMappingInfo other) { String name = combineNames(other); PatternsRequestCondition patterns = this.patternsCondition.combine(other.patternsCondition); RequestMethodsRequestCondition methods = this.methodsCondition.combine(other.methodsCondition); ... return new RequestMappingInfo( ... ); } @Nullable private String combineNames(RequestMappingInfo other) { if (this.name != null && other.name != null) { String separator = RequestMappingInfoHandlerMethodMappingNamingStrategy.SEPARATOR; return this.name + separator + other.name; } else if (this.name != null) { return this.name; } else { return other.name; } }
逻辑不难,就是类+"#"+方法的拼接,但是我们知道其实绝大部分情况下我们都从来没有指定过name属性,那么此处就不得不提这个策略接口:HandlerMethodMappingNamingStrategy了,它用于缺省的名字生成策略器
HandlerMethodMappingNamingStrategy
为处理程序HandlerMethod方法分配名称的策略接口。此接口可以在AbstractHandlerMethodMapping里配置生成name,然后这个name可以用于AbstractHandlerMethodMapping#getHandlerMethodsForMappingName(String)方法进行查询~
// @since 4.1 @FunctionalInterface // 函数式接口 public interface HandlerMethodMappingNamingStrategy<T> { // Determine the name for the given HandlerMethod and mapping. // 根据HandlerMethod 和 Mapping拿到一个name String getName(HandlerMethod handlerMethod, T mapping); }
它的唯一实现类是:RequestMappingInfoHandlerMethodMappingNamingStrategy(目前而言RequestMappingInfo的唯一实现只有@RequestMapping,但设计上是没有强制绑定必须是这个注解~)
RequestMappingInfoHandlerMethodMappingNamingStrategy
此类提供name的默认的生成规则(若没指定的话)的实现
// @since 4.1 public class RequestMappingInfoHandlerMethodMappingNamingStrategy implements HandlerMethodMappingNamingStrategy<RequestMappingInfo> { // 类级别到方法级别的分隔符(当然你也是可以改的) public static final String SEPARATOR = "#"; @Override public String getName(HandlerMethod handlerMethod, RequestMappingInfo mapping) { if (mapping.getName() != null) { // 若使用者自己指定了,那就以指定的为准 return mapping.getName(); } // 自动生成的策略 StringBuilder sb = new StringBuilder(); // 1、拿到类名 // 2、遍历每个字母,拿到所有的大写字母 // 3、用拿到的大写字母拼接 # 拼接方法名。如:TestController#getFoo()最终结果是:TC#getFoo String simpleTypeName = handlerMethod.getBeanType().getSimpleName(); for (int i = 0; i < simpleTypeName.length(); i++) { if (Character.isUpperCase(simpleTypeName.charAt(i))) { sb.append(simpleTypeName.charAt(i)); } } sb.append(SEPARATOR).append(handlerMethod.getMethod().getName()); return sb.toString(); } }
简单总结这部分逻辑如下:
- 类上的name值 + ‘#’ + 方法的name值
- 类上若没指定,默认值是:类名所有大写字母拼装
- 方法上若没指定,默认值是:方法名
name属性有什么用(如何使用)?
说了这么多,小伙伴可能还是一头雾水?有什么用?如何用?
其实在接口的JavaDoc里有提到了它的作用:应用程序可以在下面这个静态方法的帮助下按名称构建控制器方法的URL,它借助的是MvcUriComponentsBuilder的fromMappingName方法实现:
MvcUriComponentsBuilder: // 静态方法:根据mappingName,获取到一个MethodArgumentBuilder public static MethodArgumentBuilder fromMappingName(String mappingName) { return fromMappingName(null, mappingName); } public static MethodArgumentBuilder fromMappingName(@Nullable UriComponentsBuilder builder, String name) { ... Map<String, RequestMappingInfoHandlerMapping> map = wac.getBeansOfType(RequestMappingInfoHandlerMapping.class); ... for (RequestMappingInfoHandlerMapping mapping : map.values()) { // 重点:根据名称找到List<HandlerMethod> handlerMethods // 依赖的是getHandlerMethodsForMappingName()这个方法,它是从MappingRegistry里查找 handlerMethods = mapping.getHandlerMethodsForMappingName(name); } ... HandlerMethod handlerMethod = handlerMethods.get(0); Class<?> controllerType = handlerMethod.getBeanType(); Method method = handlerMethod.getMethod(); // 构建一个MethodArgumentBuilder return new MethodArgumentBuilder(builder, controllerType, method); }
说明:MethodArgumentBuilder是MvcUriComponentsBuilder的一个public静态内部类,持有controllerType、method、argumentValues、baseUrl等属性…
它的使用场景,我参考了Spring的官方文档,截图如下:
官方文档说:它能让你非常方便的在JSP页面上使用它,形如这样子:
<%@ taglib uri="http://www.springframework.org/tags" prefix="s" %> ... <a href="${s:mvcUrl('PAC#getAddress').arg(0,'US').buildAndExpand('123')}">Get Address</a>
这么写至少感觉比你这样拼装URL:pageContext.request.contextPath//people/1/addresses/china 要更加靠谱点,且更加面向对象点吧~
说明:使用此s:mvcUrl函数是要求你导入Spring标签库的支持的~
此处应有疑问:JSP早就过时了,现在谁还用呢?难道Spring4.1新推出来的name属性这么快就寿终正寝了?
当然不是,Spring作为这么优秀的框架,设计上都是功能都是非常模块化的,该功能自然不是和JSP强耦合的(Spring仅是提供了对JSP标签库而顺便内置支持一下下而已~)。
在上面我截图的最后一段话也讲到了,大致意思是:
示例依赖于Spring标记库(即META-INF/Spring.tld)中申明的mvcUrl函数,此函数的声明如下:
<function> <description>Helps to prepare a URL to a Spring MVC controller method.</description> <name>mvcUrl</name> <function-class>org.springframework.web.servlet.mvc.method.annotation.MvcUriComponentsBuilder</function-class> <function-signature>org.springframework.web.servlet.mvc.method.annotation.MvcUriComponentsBuilder.MethodArgumentBuilder fromMappingName(java.lang.String)</function-signature> </function>
可见它最终的处理函数是MvcUriComponentsBuilder.fromMappingName(java.lang.String)()这个方法而已(文末有详细介绍,请关联起来看本文)~
因为,如果你是其它模版技术(如Thymeleaf)也是很容易自定义一个这样类似的函数的,那么你就依旧可以使用此便捷、强大的功能来帮助你开发。
通过name属性的引入,就顺利过渡到了接下来要将的重点,也是本文的重中之重:Spring MVC支持的强大的URI Builder模式。