你知道@RequestMapping的name属性有什么用吗?带你了解URI Builder模式(UriComponents/UriComponentsBuilder)【享学Spring MVC】(上)

简介: 你知道@RequestMapping的name属性有什么用吗?带你了解URI Builder模式(UriComponents/UriComponentsBuilder)【享学Spring MVC】(上)

前言


不知这个标题能否勾起你的好奇心和求知欲?在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();
  }
}


简单总结这部分逻辑如下:


  1. 类上的name值 + ‘#’ + 方法的name值
  2. 类上若没指定,默认值是:类名所有大写字母拼装
  3. 方法上若没指定,默认值是:方法名


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的官方文档,截图如下:


image.png


官方文档说:它能让你非常方便的在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模式。

相关文章
|
11天前
|
设计模式 存储 前端开发
MVVM、MVC、MVP三种常见软件架构设计模式的区别
MVC、MVP 和 MVVM 是三种常见的软件架构设计模式,主要通过分离关注点的方式来组织代码结构,优化开发效率。
33 12
|
11天前
|
前端开发 Java Spring
Spring MVC 是如何对对象参数进行校验的
【6月更文挑战第4天】对象参数校验是使用 SpringMVC 时常用的功能,这篇文章尝试分析了,Spring 是如何实现这一功能的。
26 5
|
1天前
|
前端开发 Java Maven
如何在Spring MVC中实现图片的上传和下载功能
如何在Spring MVC中实现图片的上传和下载功能
|
2天前
|
设计模式 存储 前端开发
MVC(Model-View-Controller)是一种软件设计模式,用于将应用程序的输入逻辑、业务逻辑和用户界面逻辑分离
【6月更文挑战第17天】**MVC模式**是软件设计模式,用于分离输入逻辑、业务逻辑和用户界面。模型处理数据和业务,视图展示数据,控制器协调两者响应用户请求。优点包括:关注点分离、提高开发效率、简化测试、支持多视图及便于大型项目管理。
16 3
|
5天前
|
前端开发 Java Spring
Spring MVC 请求处理流程
Spring MVC 请求处理流程
6 0
|
9天前
|
JSON 前端开发 Java
Spring MVC 级联对象参数校验
【6月更文挑战第6天】在 Spring MVC 的使用过程中,我们会发现很多非常符合直觉的功能特性,但往往我们会习惯这种「被照顾得很好」的开发方式,依靠直觉去判断很多功能特性的用法。
14 1
|
12天前
|
前端开发 Java Spring
自定义 Spring MVC Controller 方法参数处理
【6月更文挑战第3天】在 Spring MVC Controller 的方法参数,Spring 会自动为我们注入一些特殊的参数值,比如 HttpServletRequest、HttpServletResponse 等对象,或者 HTTP 请求参数。
51 0
|
13天前
|
存储 前端开发 数据库
MVC模式和三层架构
MVC模式和三层架构
20 2
|
13天前
|
安全 Java 数据安全/隐私保护
给 Spring Security OAuth 增加新的授权模式
【6月更文挑战第1天】这篇我们来试着参考密码模式,给 Spring Security OAuth 增加一个手机验证码模式。以下内容会与之前的文章内容有关联,因此在此之前,可以先阅读之前的几篇文章,回顾一下这些内容。
38 0
|
13天前
|
JSON 前端开发 Java
Spring第四课,MVC终章,应用分层的好处,总结
Spring第四课,MVC终章,应用分层的好处,总结