SpringBoot实战之高效使用枚举参数(原理篇)案例详解

找入口

对 Spring 有一定基础的同学一定知道,请求入口是DispatcherServlet,所有的请求最终都会落到doDispatch方法中的ha.handle(processedRequest, response, mappedHandler.getHandler())逻辑。我们从这里出发,一层一层向里扒。

跟着代码深入,我们会找到org.springframework.web.method.support.InvocableHandlerMethod#invokeForRequest的逻辑:

public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
        Object... providedArgs) throws Exception {

    Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
    if (logger.isTraceEnabled()) {
        logger.trace("Arguments: " + Arrays.toString(args));
    }
    return doInvoke(args);
}

可以看出,这里面通过getMethodArgumentValues方法处理参数,然后调用doInvoke方法获取返回值。

继续深入,能够找到org.springframework.web.method.annotation.RequestParamMethodArgumentResolver#resolveArgument方法,这个方法就是解析参数的逻辑。

试想一下,如果是我们自己实现这段逻辑,会怎么做呢?

  1. 获取输入参数
  2. 找到目标参数
  3. 检查是否需要特殊转换逻辑
  4. 如果需要,进行转换
  5. 如果不需要,直接返回

获取输入参数的逻辑在org.springframework.web.method.annotation.RequestParamMethodArgumentResolver#resolveName,单参数返回的是 String 类型,多参数返回 String 数组。核心代码如下:

String[] paramValues = request.getParameterValues(name);
if (paramValues != null) {
    arg = (paramValues.length == 1 ? paramValues[0] : paramValues);
}

所以说,无论我们的目标参数是什么,输入参数都是 String 类型或 String 数组,然后 Spring 把它们转换为我们期望的类型。

找到目标参数的逻辑在DispatcherServlet中,根据 uri 找到对应的 Controller 处理方法,找到方法就找到了目标参数类型。

接下来就是检查是否需要转换逻辑,也就是org.springframework.validation.DataBinder#convertIfNecessary,顾名思义,如果需要就转换,将字符串类型转换为目标类型。在我们的例子中,就是将 String 转换为枚举值。

查找转换器

继续深扒,会在org.springframework.beans.TypeConverterDelegate#convertIfNecessary方法中找到这么一段逻辑:

if (conversionService.canConvert(sourceTypeDesc, typeDescriptor)) {
    try {
        return (T) conversionService.convert(newValue, sourceTypeDesc, typeDescriptor);
    }
    catch (ConversionFailedException ex) {
        // fallback to default conversion logic below
        conversionAttemptEx = ex;
    }
}

这段逻辑中,调用了org.springframework.core.convert.support.GenericConversionService#canConvert方法,检查是否可转换,如果可以转换,将会执行类型转换逻辑。

检查是否可转换的本质就是检查是否能够找到对应的转换器。如果能找到,就用找到的转换器开始转换逻辑,如果找不到,那就是不能转换,走其他逻辑。

我们可以看看查找转换器的代码org.springframework.core.convert.support.GenericConversionService#getConverter,可以对我们自己写代码有一些启发:

private final Map<ConverterCacheKey, GenericConverter> converterCache = new ConcurrentReferenceHashMap<>(64);

protected GenericConverter getConverter(TypeDescriptor sourceType, TypeDescriptor targetType) {
    ConverterCacheKey key = new ConverterCacheKey(sourceType, targetType);
    GenericConverter converter = this.converterCache.get(key);
    if (converter != null) {
        return (converter != NO_MATCH ? converter : null);
    }

    converter = this.converters.find(sourceType, targetType);
    if (converter == null) {
        converter = getDefaultConverter(sourceType, targetType);
    }

    if (converter != null) {
        this.converterCache.put(key, converter);
        return converter;
    }

    this.converterCache.put(key, NO_MATCH);
    return null;
}

转换为伪代码就是:

  1. 根据参数类型和目标类型,构造缓存 key
  2. 根据缓存 key,从缓存中查询转换器
  3. 如果能找到且不是 NO_MATCH,返回转换器;如果是 NO_MATCH,返回 null;如果未找到,继续
  4. 通过org.springframework.core.convert.support.GenericConversionService.Converters#find查询转换器
  5. 如果未找到,检查源类型和目标类型是否可以强转,也就是类型一致。如果是,返回 NoOpConverter,如果否,返回 null。
  6. 检查找到的转换器是否为 null,如果不是,将转换器加入到缓存中,返回该转换器
  7. 如果否,在缓存中添加 NO_MATCH 标识,返回 null

Spring 内部使用Map作为缓存,用来存储通用转换器接口GenericConverter,这个接口会是我们自定义转换器的包装类。我们还可以看到,转换器缓存用的是ConcurrentReferenceHashMap,这个类是线程安全的,可以保证并发情况下,不会出现异常存储。但是getConverter方法没有使用同步逻辑。换句话说,并发请求时,可能存在性能损耗。不过,对于 web 请求场景,并发损耗好过阻塞等待。

我们在看下 Spring 是如何查找转换器的,在org.springframework.core.convert.support.GenericConversionService.Converters#find中就是找到对应转换器的核心逻辑:

private final Map<ConvertiblePair, ConvertersForPair> converters = new ConcurrentHashMap<>(256);

@Nullable
public GenericConverter find(TypeDescriptor sourceType, TypeDescriptor targetType) {
    // Search the full type hierarchy
    List<Class<?>> sourceCandidates = getClassHierarchy(sourceType.getType());
    List<Class<?>> targetCandidates = getClassHierarchy(targetType.getType());
    for (Class<?> sourceCandidate : sourceCandidates) {
        for (Class<?> targetCandidate : targetCandidates) {
            ConvertiblePair convertiblePair = new ConvertiblePair(sourceCandidate, targetCandidate);
            GenericConverter converter = getRegisteredConverter(sourceType, targetType, convertiblePair);
            if (converter != null) {
                return converter;
            }
        }
    }
    return null;
}

@Nullable
private GenericConverter getRegisteredConverter(TypeDescriptor sourceType,
        TypeDescriptor targetType, ConvertiblePair convertiblePair) {

    // Check specifically registered converters
    ConvertersForPair convertersForPair = this.converters.get(convertiblePair);
    if (convertersForPair != null) {
        GenericConverter converter = convertersForPair.getConverter(sourceType, targetType);
        if (converter != null) {
            return converter;
        }
    }
    // Check ConditionalConverters for a dynamic match
    for (GenericConverter globalConverter : this.globalConverters) {
        if (((ConditionalConverter) globalConverter).matches(sourceType, targetType)) {
            return globalConverter;
        }
    }
    return null;
}

我们可以看到,Spring 是通过源类型和目标类型组合起来,查找对应的转换器。而且,Spring 还通过getClassHierarchy方法,将源类型和目标类型的家族族谱全部列出来,用双层 for 循环遍历查找。

上面的代码中,还有一个matches方法,在这个方法里面,调用了ConverterFactory#getConverter方法,也就是用这个工厂方法,创建了指定类型的转换器。

private final ConverterFactory<Object, Object> converterFactory;

public boolean matches(TypeDescriptor sourceType, TypeDescriptor targetType) {
    boolean matches = true;
    if (this.converterFactory instanceof ConditionalConverter) {
        matches = ((ConditionalConverter) this.converterFactory).matches(sourceType, targetType);
    }
    if (matches) {
        Converter<?, ?> converter = this.converterFactory.getConverter(targetType.getType());
        if (converter instanceof ConditionalConverter) {
            matches = ((ConditionalConverter) converter).matches(sourceType, targetType);
        }
    }
    return matches;
}

类型转换

经过上面的逻辑,已经找到判断可以进行转换。其核心逻辑就是已经找到对应的转换器了,下面就是转换逻辑,在org.springframework.core.convert.support.GenericConversionService#convert中:

public Object convert(@Nullable Object source, @Nullable TypeDescriptor sourceType, TypeDescriptor targetType) {
    Assert.notNull(targetType, "Target type to convert to cannot be null");
    if (sourceType == null) {
        Assert.isTrue(source == null, "Source must be [null] if source type == [null]");
        return handleResult(null, targetType, convertNullSource(null, targetType));
    }
    if (source != null && !sourceType.getObjectType().isInstance(source)) {
        throw new IllegalArgumentException("Source to convert from must be an instance of [" +
                sourceType + "]; instead it was a [" + source.getClass().getName() + "]");
    }
    GenericConverter converter = getConverter(sourceType, targetType);
    if (converter != null) {
        Object result = ConversionUtils.invokeConverter(converter, source, sourceType, targetType);
        return handleResult(sourceType, targetType, result);
    }
    return handleConverterNotFound(source, sourceType, targetType);
}

其中的GenericConverter converter = getConverter(sourceType, targetType)就是前文中getConverter方法。此处还是可以给我们编码上的一些借鉴的:getConverter方法在canConvert中调用了一次,然后在后续真正转换的时候又调用一次,这是参数转换逻辑,我们该怎么优化这种同一请求内多次调用相同逻辑或者请求相同参数呢?那就是使用缓存。为了保持一次请求中前后两次数据的一致性和请求的高效,推荐使用内存缓存。

执行到这里,直接调用ConversionUtils.invokeConverter(converter, source, sourceType, targetType)转换,其内部是使用org.springframework.core.convert.support.GenericConversionService.ConverterFactoryAdapter#convert方法,代码如下:

public Object convert(@Nullable Object source, TypeDescriptor sourceType, TypeDescriptor targetType) {
    if (source == null) {
        return convertNullSource(sourceType, targetType);
    }
    return this.converterFactory.getConverter(targetType.getObjectType()).convert(source);
}

这里就是调用ConverterFactory工厂类构建转换器(即IdCodeToEnumConverterFactory类的getConverter方法),然后调用转换器的conver方法(即IdCodeToEnumConverter类的convert方法),将输入参数转换为目标类型。具体实现可以看一下实战篇中的代码,这里不做赘述。

至此,我们把整个路程通了下来。

文末总结

在本文中,我们跟随源码找到自定义转换器工厂类和转换器类的实现逻辑。这里需要强调一下的是,由于实战篇中我们用到的例子是简单参数的方式,也就是Controller的方法参数都是直接参数,没有包装成对象。这样的话,Spring 是通过RequestParamMethodArgumentResolver处理参数。如果是包装成对象,会使用ModelAttributeMethodProcessor处理参数。这两个处理类中查找类型转换器逻辑都是相同的。

无论是GET请求,还是传参式的POST请求(即Form模式),都可以使用上面这种方式,实现枚举参数的类型转换。但是是 HTTP Body 方式却不行,为什么呢?

Spring 对于 body 参数是通过RequestResponseBodyMethodProcessor处理的,其内部使用了MappingJackson2HttpMessageConverter转换器,逻辑完全不同。所以,想要实现 body 的类型转换,还需要走另外一种方式。将在下一篇中给出。

到此这篇关于SpringBoot实战之高效使用枚举参数(原理篇)案例详解的文章就介绍到这了,更多相关SpringBoot实战之高效使用枚举参数(原理篇)内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • SpringBoot实战:Spring如何找到对应转换器优雅使用枚举参数

    目录 找入口 请求入口是DispatcherServlet 查找转换器 Spring 如何查找转换器 类型转换 跟随源码找到自定义转换器工厂类和转换器类的实现逻辑 无论是GET请求,还是传参式的POST请求(即Form模式) 找入口 请求入口是DispatcherServlet 所有的请求最终都会落到doDispatch方法中的 ha.handle(processedRequest, response, mappedHandler.getHandler())逻辑. 我们从这里出发,一层一层向里扒

  • Java SpringBoot在RequestBody中高效的使用枚举参数原理案例详解

    在优雅的使用枚举参数(原理篇)中我们聊过,Spring对于不同的参数形式,会采用不同的处理类处理参数,这种形式,有些类似于策略模式.将针对不同参数形式的处理逻辑,拆分到不同处理类中,减少耦合和各种if-else逻辑.本文就来扒一扒,RequestBody参数中使用枚举参数的原理. 找入口 对 Spring 有一定基础的同学一定知道,请求入口是DispatcherServlet,所有的请求最终都会落到doDispatch方法中的ha.handle(processedRequest, respons

  • Springboot JPA 枚举Enum类型存入到数据库的操作

    1.使用JPA 的@Enumerated 注解 ,可以直接将Enum映射到数据库中. 但是value的值只有两种方式选择,一种是使用枚举的序号映射,一种是枚举的名称来映射. public enum EnumType { /** Persist enumerated type property or field as an integer. */ ORDINAL, /** Persist enumerated type property or field as a string. */ STRIN

  • 一篇文章带了解如何用SpringBoot在RequestBody中优雅的使用枚举参数

    目录 确认需求 定义枚举和对象 实现转换逻辑 方案一:精准攻击 方案二:全范围攻击 测试 总结 确认需求 需求与前文类似,只不过这里需要是在 RequestBody 中使用.与前文不同的是,这种请求是通过 Http Body 的方式传输到后端,通常是 json 或 xml 格式,Spring 默认借助 Jackson 反序列化为对象. 同样的,我们需要在枚举中定义 int 类型的 id.String 类型的 code,id 取值不限于序号(即从 0 开始的 orinal 数据),code 不限于

  • SpringBoot之使用枚举参数案例详解

    接口开发过程中不免有表示类型的参数,比如 0 表示未知,1 表示男,2 表示女.通常有两种做法,一种是用数字表示,另一种是使用枚举实现. 使用数字表示就是通过契约形式,约定每个数字表示的含义,接口接收到参数,就按照约定对类型进行判断,接口维护成本比较大. 在 Spring 体系中,使用枚举表示,是借助 Spring 的 Converter 机制,可以将数字或字符串对应到枚举的序号或者 name,然后将前端的输入转换为枚举类型. 在场景不复杂的场景中,枚举可以轻松胜任. 于是,迅速实现逻辑,准备提

  • springboot枚举类型传递的步骤

    目录 测试 Converter 灵活化 在本周写项目时,需要将枚举类型作为参数进行传递. 测试 首先先建立一个枚举类: public enum ScoreType { TOTAL_SCORE("总评成绩"), MIDDLE_SCORE("期中成绩"), FINAL_SCORE("期末成绩"); String des; // 描述 ScoreType(String des) { this.des = des; } public String get

  • SpringBoot实战之高效使用枚举参数(原理篇)案例详解

    找入口 对 Spring 有一定基础的同学一定知道,请求入口是DispatcherServlet,所有的请求最终都会落到doDispatch方法中的ha.handle(processedRequest, response, mappedHandler.getHandler())逻辑.我们从这里出发,一层一层向里扒. 跟着代码深入,我们会找到org.springframework.web.method.support.InvocableHandlerMethod#invokeForRequest的

  • SpringBoot在RequestBody中使用枚举参数案例详解

    前文说到 优雅的使用枚举参数 和 实现原理,本文继续说一下如何在 RequestBody 中优雅使用枚举. 本文先上实战,说一下如何实现.在 优雅的使用枚举参数 代码的基础上,我们继续实现. 确认需求 需求与前文类似,只不过这里需要是在 RequestBody 中使用.与前文不同的是,这种请求是通过 Http Body 的方式传输到后端,通常是 json 或 xml 格式,Spring 默认借助 Jackson 反序列化为对象. 同样的,我们需要在枚举中定义 int 类型的 id.String

  • SpringBoot实战之实现结果的优雅响应案例详解

    今天说一下 Spring Boot 如何实现优雅的数据响应:统一的结果响应格式.简单的数据封装. 前提 无论系统规模大小,大部分 Spring Boot 项目是提供 Restful + json 接口,供前端或其他服务调用,格式统一规范,是程序猿彼此善待彼此的象征,也是减少联调挨骂的基本保障. 通常响应结果中需要包含业务状态码.响应描述.响应时间戳.响应内容,比如: { "code": 200, "desc": "查询成功", "tim

  • SpringBoot实战之处理异常案例详解

    前段时间写了一篇关于实现统一响应信息的博文,根据文中实战操作,能够解决正常响应的一致性,但想要实现优雅响应,还需要优雅的处理异常响应,所以有了这篇内容. 作为后台服务,能够正确的处理程序抛出的异常,并返回友好的异常信息是非常重要的,毕竟我们大部分代码都是为了 处理异常情况.而且,统一的异常响应,有助于客户端理解服务端响应,并作出正确处理,而且能够提升接口的服务质量. SpringBoot提供了异常的响应,可以通过/error请求查看效果: 这是从浏览器打开的场景,也就是请求头不包括content

  • SpringBoot之自定义Filter获取请求参数与响应结果案例详解

    一个系统上线,肯定会或多或少的存在异常情况.为了更快更好的排雷,记录请求参数和响应结果是非常必要的.所以,Nginx 和 Tomcat 之类的 web 服务器,都提供了访问日志,可以帮助我们记录一些请求信息. 本文是在我们的应用中,定义一个Filter来实现记录请求参数和响应结果的功能. 有一定经验的都知道,如果我们在Filter中读取了HttpServletRequest或者HttpServletResponse的流,就没有办法再次读取了,这样就会造成请求异常.所以,我们需要借助 Spring

  • SpringBoot进行参数校验的方法详解

    目录 介绍 1.SpringBoot中集成参数校验 1.1引入依赖 1.2定义参数实体类 1.3定义校验类进行测试 1.4打开接口文档模拟提交数据 2.参数异常加入全局异常处理器 3.自定义参数校验 3.1创建自定义注解 3.2自定义校验逻辑 3.3在字段上增加注解 3.4体验效果 4.分组校验 4.1定义分组接口 4.2在模型中给参数分配分组 4.3体现效果 介绍 在日常的接口开发中,为了防止非法参数对业务造成影响,经常需要对接口的参数进行校验,例如登录的时候需要校验用户名和密码是否为空,添加

  • SpringBoot Starter依赖原理与实例详解

    目录 1 Starter 2 了解 spring.factories机制 2.1 不同包路径下的依赖注入 2.2 spring.factories 机制 3 spring.factories 机制的实现源码分析 4 程序运行入口run() 1 Starter 在开发 SpringBoot 项目的时候,我们常常通过 Maven 导入自动各种依赖,其中很多依赖都是以 xxx-starter 命名的. 像这种 starter 依赖是怎么工作的呢? 2 了解 spring.factories机制 导入一

  • SpringBoot常见get/post请求参数处理、参数注解校验及参数自定义注解校验详解

    目录 springboot常见httpget,post请求参数处理 PathVaribale获取url路径的数据 RequestParam获取请求参数的值 注意 GET参数校验 POSTJSON参数校验 自定义注解校验 总结 spring boot 常见http get ,post请求参数处理 在定义一个Rest接口时通常会利用GET.POST.PUT.DELETE来实现数据的增删改查:这几种方式有的需要传递参数,后台开发人员必须对接收到的参数进行参数验证来确保程序的健壮性 GET一般用于查询数

随机推荐