你知道@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模式。

相关文章
|
6月前
|
前端开发 Java 测试技术
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@RequestParam
本文介绍了 `@RequestParam` 注解的使用方法及其与 `@PathVariable` 的区别。`@RequestParam` 用于从请求中获取参数值(如 GET 请求的 URL 参数或 POST 请求的表单数据),而 `@PathVariable` 用于从 URL 模板中提取参数。文章通过示例代码详细说明了 `@RequestParam` 的常用属性,如 `required` 和 `defaultValue`,并展示了如何用实体类封装大量表单参数以简化处理流程。最后,结合 Postman 测试工具验证了接口的功能。
315 0
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@RequestParam
|
6月前
|
JSON 前端开发 Java
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@RequestBody
`@RequestBody` 是 Spring 框架中的注解,用于将 HTTP 请求体中的 JSON 数据自动映射为 Java 对象。例如,前端通过 POST 请求发送包含 `username` 和 `password` 的 JSON 数据,后端可通过带有 `@RequestBody` 注解的方法参数接收并处理。此注解适用于传递复杂对象的场景,简化了数据解析过程。与表单提交不同,它主要用于接收 JSON 格式的实体数据。
477 0
|
6月前
|
前端开发 Java 微服务
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@PathVariable
`@PathVariable` 是 Spring Boot 中用于从 URL 中提取参数的注解,支持 RESTful 风格接口开发。例如,通过 `@GetMapping(&quot;/user/{id}&quot;)` 可以将 URL 中的 `{id}` 参数自动映射到方法参数中。若参数名不一致,可通过 `@PathVariable(&quot;自定义名&quot;)` 指定绑定关系。此外,还支持多参数占位符,如 `/user/{id}/{name}`,分别映射到方法中的多个参数。运行项目后,访问指定 URL 即可验证参数是否正确接收。
290 0
|
6月前
|
JSON 前端开发 Java
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@RequestMapping
@RequestMapping 是 Spring MVC 中用于请求地址映射的注解,可作用于类或方法上。类级别定义控制器父路径,方法级别进一步指定处理逻辑。常用属性包括 value(请求地址)、method(请求类型,如 GET/POST 等,默认 GET)和 produces(返回内容类型)。例如:`@RequestMapping(value = &quot;/test&quot;, produces = &quot;application/json; charset=UTF-8&quot;)`。此外,针对不同请求方式还有简化注解,如 @GetMapping、@PostMapping 等。
257 0
|
6月前
|
JSON 前端开发 Java
微服务——SpringBoot使用归纳——Spring Boot中的MVC支持——@RestController
本文主要介绍 Spring Boot 中 MVC 开发常用的几个注解及其使用方式,包括 `@RestController`、`@RequestMapping`、`@PathVariable`、`@RequestParam` 和 `@RequestBody`。其中重点讲解了 `@RestController` 注解的构成与特点:它是 `@Controller` 和 `@ResponseBody` 的结合体,适用于返回 JSON 数据的场景。文章还指出,在需要模板渲染(如 Thymeleaf)而非前后端分离的情况下,应使用 `@Controller` 而非 `@RestController`
201 0
|
6月前
|
Java 测试技术 微服务
微服务——SpringBoot使用归纳——Spring Boot中的项目属性配置——少量配置信息的情形
本课主要讲解Spring Boot项目中的属性配置方法。在实际开发中,测试与生产环境的配置往往不同,因此不应将配置信息硬编码在代码中,而应使用配置文件管理,如`application.yml`。例如,在微服务架构下,可通过配置文件设置调用其他服务的地址(如订单服务端口8002),并利用`@Value`注解在代码中读取这些配置值。这种方式使项目更灵活,便于后续修改和维护。
90 0
|
2月前
|
前端开发 Java API
Spring Cloud Gateway Server Web MVC报错“Unsupported transfer encoding: chunked”解决
本文解析了Spring Cloud Gateway中出现“Unsupported transfer encoding: chunked”错误的原因,指出该问题源于Feign依赖的HTTP客户端与服务端的`chunked`传输编码不兼容,并提供了具体的解决方案。通过规范Feign客户端接口的返回类型,可有效避免该异常,提升系统兼容性与稳定性。
177 0
|
2月前
|
SQL Java 数据库连接
Spring、SpringMVC 与 MyBatis 核心知识点解析
我梳理的这些内容,涵盖了 Spring、SpringMVC 和 MyBatis 的核心知识点。 在 Spring 中,我了解到 IOC 是控制反转,把对象控制权交容器;DI 是依赖注入,有三种实现方式。Bean 有五种作用域,单例 bean 的线程安全问题及自动装配方式也清晰了。事务基于数据库和 AOP,有失效场景和七种传播行为。AOP 是面向切面编程,动态代理有 JDK 和 CGLIB 两种。 SpringMVC 的 11 步执行流程我烂熟于心,还有那些常用注解的用法。 MyBatis 里,#{} 和 ${} 的区别很关键,获取主键、处理字段与属性名不匹配的方法也掌握了。多表查询、动态
110 0
|
2月前
|
JSON 前端开发 Java
第05课:Spring Boot中的MVC支持
第05课:Spring Boot中的MVC支持
148 0
|
8月前
|
SQL Java 数据库连接
对Spring、SpringMVC、MyBatis框架的介绍与解释
Spring 框架提供了全面的基础设施支持,Spring MVC 专注于 Web 层的开发,而 MyBatis 则是一个高效的持久层框架。这三个框架结合使用,可以显著提升 Java 企业级应用的开发效率和质量。通过理解它们的核心特性和使用方法,开发者可以更好地构建和维护复杂的应用程序。
359 29

热门文章

最新文章