Quantcast
Channel: Baeldung
Viewing all articles
Browse latest Browse all 4535

A Custom Data Binder in Spring MVC

$
0
0

1. Overview

This article will show how we can use Spring’s Data Binding mechanism in order to make our code more clear and readable by applying automatic primitives to objects conversions.

2. Bind Request Parameters

By default, Spring only knows how to convert simple types. In other words, once we submit data to controller Int, String or Boolean type of data, it will be bound to appropriate Java types automatically.

But in real-world projects, that won’t be enough, as we might need to bind more more complex types of objects.

2.1. Individual Objects

Let’s start simple and first bind a simple type; we’ll have to provide a custom implementation of the Converter<S, T> interface where S is the type we are converting from, and T is the type we are converting to:

@Component
public class StringToLocalDateTimeConverter
  implements Converter<String, LocalDateTime> {

    @Override
    public LocalDateTime convert(String source) {
        return LocalDateTime.parse(
          source, DateTimeFormatter.ISO_LOCAL_DATE_TIME);
    }
}

Now we can use the following syntax in our controller:

@GetMapping("/findbydate/{date}")
public GenericEntity findByDate(@PathVariable("date") LocalDateTime date) {
    return ...;
}

2.2. Hierarchy of Objects

Sometimes we need to convert the entire tree of the object hierarchy and it makes sense to have a more centralized binding rather than a set of individual converters.

In this case, we can implement ConverterFactory<S, R> where S will be the type we are converting from and R to be the base type defining the range of classes we can convert to:

@Component
public class StringToEnumConverterFactory
  implements ConverterFactory<String, Enum> {

    private static class StringToEnumConverter<T extends Enum> 
      implements Converter<String, T> {

        private Class<T> enumType;

        public StringToEnumConverter(Class<T> enumType) {
            this.enumType = enumType;
        }

        public T convert(String source) {
            return (T) Enum.valueOf(this.enumType, source.trim());
        }
    }

    @Override
    public <T extends Enum> Converter<String, T> getConverter(
      Class<T> targetType) {
        return new StringToEnumConverter(targetType);
    }
}

As we can see, the only method that must implement is getConverter() which returns converter for needed type. The conversion process then is delegated to this converter.

So, suppose we have an Enum:

public enum Modes {
    ALPHA, BETA;
}

We can let Spring convert incoming values automatically:

@GetMapping("/findbymode/{mode}")
public GenericEntity findByEnum(@PathVariable("mode") Modes mode) {
    return ...;
}

3. Bind Domain Objects

There are cases when we want to bind data to objects, but it comes either in a non-direct way (for example, from Session, Header or Cookie variables) or even stored in a data source. In those cases, we need to use a different solution.

3.1. Custom Argument Resolver

First of all, we will define an annotation for such parameters:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface Version {
}

Then, we will implement a custom HandlerMethodArgumentResolver:

public class HeaderVersionArgumentResolver
  implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter methodParameter) {
        return methodParameter.getParameterAnnotation(Version.class) != null;
    }

    @Override
    public Object resolveArgument(
      MethodParameter methodParameter, 
      ModelAndViewContainer modelAndViewContainer, 
      NativeWebRequest nativeWebRequest, 
      WebDataBinderFactory webDataBinderFactory) throws Exception {
 
        HttpServletRequest request 
          = (HttpServletRequest) nativeWebRequest.getNativeRequest();

        return request.getHeader("Version");
    }
}

The last thing is letting Spring know where to search for them:

@Configuration
public class WebConfig extends WebMvcConfigurerAdapter {

    //...

    @Override
    public void addArgumentResolvers(
      List<HandlerMethodArgumentResolver> argumentResolvers) {
        argumentResolvers.add(new HeaderVersionArgumentResolver());
    }
}

That’s it. Now we can use it in a controller:

@GetMapping("/entity/{id}")
public ResponseEntity findByVersion(
  @PathVariable Long id, @Version String version) {
    return ...;
}

As we can see, HandlerMethodArgumentResolver‘s resolveArgument() method returns an Object. In other words, we could return any object, not only String.

4. Conclusion

As a result, we got rid of many routine conversions and let Spring do most stuff for us. At the end, let’s conclude:

  • For individual simple type to object conversions we should use Converter implementation
  • For encapsulating conversion logics for range of objects, we can try ConverterFactory implementation
  • For any data comes indirectly or it is required to apply additional logics to retrieve the associated data it’s better to use HandlerMethodArgumentResolver

As usually, all the examples can be always found at our GitHub repository.


Viewing all articles
Browse latest Browse all 4535

Trending Articles