ModelMapper中Converter/AbstractConverter与Provider的适用场景咨询

Hey there! Let’s break down these ModelMapper components clearly so you know exactly when to reach for each one—no more guessing.

1. Core Component Breakdown #

AbstractConverter #

This is ModelMapper’s simplified, boilerplate-free Converter implementation. It handles all the basic interface scaffolding, leaving you only to override the convert(Object source) method with your actual conversion logic.

• Best for: Straightforward type conversion (like your string-to-inner-DTO use case) where you don’t need access to full mapping context, just the source value.
• Your scenario check: Using it to convert a string to a nested DTO is totally reasonable—this is exactly what AbstractConverter was built for. It keeps your conversion code clean and focused on the logic that matters.

Converter (Interface) #

The foundational conversion interface, offering more flexibility than AbstractConverter. Its convert(MappingContext<S, D> context) method gives you access to the full mapping context: source object, target object, property metadata, and more.

• Best for: Conversion logic that depends on context. For example:
  • You need to use other properties from the source object to calculate the target value
  • You need to modify an existing target object instance instead of creating a new one
  • You need to handle edge cases based on the current mapping’s context

Provider #

Don’t confuse this with converters—Providers are for creating target object instances, not converting values.

• Best for:
  • When your target class has no no-arg constructor (ModelMapper can’t auto-instantiate it otherwise)
  • When you need custom instance creation logic: e.g., pulling instances from a dependency injection container, using factory methods, initializing with default values, or enforcing singletons
  • Example: If your inner DTO can only be created via SmallDto.fromString(String input) instead of a constructor, a Provider tells ModelMapper how to spin up that instance before any conversion logic runs.

2. Your Specific Use Case: String to Inner DTO #

Your current approach with AbstractConverter is perfectly valid. Here’s a quick code example to illustrate how clean it can be:

public class StringToSmallDtoConverter extends AbstractConverter<String, SmallDto> {
    @Override
    protected SmallDto convert(String source) {
        // Your custom logic: parse the string, populate the DTO
        String[] parts = source.split("\\|");
        return new SmallDto(parts[0], parts[1]);
    }
}

// Register it with ModelMapper
modelMapper.addConverter(new StringToSmallDtoConverter());

When should you switch to using a Provider? Let’s say your SmallDto doesn’t have a public constructor—instead, it uses a factory method:

// Custom Provider to create SmallDto instances
Provider<SmallDto> smallDtoProvider = request -> SmallDto.fromString("default");

// Tie it to your mapping
modelMapper.typeMap(SourceEntity.class, TargetDto.class)
    .addMappings(mapper -> mapper.withProvider(smallDtoProvider)
        .map(SourceEntity::getSmallDtoString, TargetDto::setInnerSmallDto));

3. Quick Note on Property Configuration #

Since you mentioned needing to set properties, here are common scenarios you might run into:

• Ignore specific properties: Use skip() in your type map:

  modelMapper.typeMap(Source.class, Target.class)
      .addMappings(m -> m.skip(Target::setUnwantedField));
  

• Custom property mappings: Map a source field to a different target field:

  modelMapper.typeMap(Source.class, Target.class)
      .addMappings(m -> m.map(Source::getSourceField, Target::setTargetField));
  

• Nested object customization: For complex nested mappings, combine a Provider (to create the nested instance) with a Converter (to populate its values) if the auto-mapping doesn’t fit your needs.

内容的提问来源于stack exchange，提问作者magnoz