mapstruct实现各个实体间的类型转换（DTO转BO、BO转Entity）的实践

一、引入

在没有遇见mapstruct的时候，实现各个实体之间的转换，都是手动转换实现的，属性少一带你还好，当属性一多，代码就会变得很冗余，没必要的非逻辑的代码就会加多。。。。

比如：

public class UserDTO {
    private String username;
    private String email;
    private boolean isActive;
 
    // Getters and setters
    // Constructor
    // Other methods as needed
}
 
// BO: UserBO.java
public class UserBO {
    private String username;
    private String email;
    private boolean isActive;
 
    // Getters and setters
    // Constructor
    // Business methods as needed
}

手动实现类型转换：

public class UserConverter {
 
    public static UserBO convertToBO(UserDTO userDTO) {
        UserBO userBO = new UserBO();
        userBO.setUsername(userDTO.getUsername());
        userBO.setEmail(userDTO.getEmail());
        userBO.setActive(userDTO.isActive());
        return userBO;
    }
 
    public static UserDTO convertToDTO(UserBO userBO) {
        UserDTO userDTO = new UserDTO();
        userDTO.setUsername(userBO.getUsername());
        userDTO.setEmail(userBO.getEmail());
        userDTO.setActive(userBO.isActive());
        return userDTO;
    }
}

这种方式，就很费时费力，一个突然的契机，我在学习DDD（领域驱动设计）架构的时候，发现up使用的mapstruct做的实体之间的转换，后面也了解了一下，发现这个工具还是很优秀的。

二、Mapstruct

MapStruct 是一个代码生成器，用于创建实现Java Bean之间转换的扩展映射器，它基于约定优于配置的方法极大地简化了 Java bean 之间映射的实现，我们只需要创建接口，MapStruct就会在编译时自动创建一个具体的实现进行对象的转换

2.1、Mapstruct和BeanUtil的比较 

Mapstruct的性能远远高于BeanUtils，这应该是大佬使用Mapstruct的主要原因，下面是我的测试结果，可以看出随着属性个数的增加，BeanUtils的耗时也在增加，并且BeanUtils的耗时跟属性个数成正比，而Mapstruct的耗时却一直是1秒，所以从对比数据可以看出Mapstruct是非常优秀的，其性能远远超过BeanUtil


BeanUtils 只能同属性映射，或者在属性相同的情况下，允许被映射的对象属性少；但当遇到被映射的属性数据类型被修改或者被映射的字段名被修改，则会导致映射失败。

2.2、优势，为什么选择Mapstruct

2.3、快速入门

2.3.1、引入依赖

 <dependency>
            <groupId>org.mapstruct</groupId>
            <artifactId>mapstruct</artifactId>
            <version>1.4.2.Final</version>
        </dependency>
        <dependency>
            <groupId>org.mapstruct</groupId>
            <artifactId>mapstruct-processor</artifactId>
            <version>1.4.2.Final</version>
        </dependency>

2.3.1、定义DTO和BO 

/**
 * SubjectCategoryDTO
 */
@Data
public class SubjectCategoryDTO implements Serializable {
    private static final long serialVersionUID = -36288445272926615L;
    private Long id;
    private String categoryName;
    private Integer categoryType;
    private String imageUrl;
    private Long parentId;
    private Integer count;
 
}

@Data
public class SubjectCategoryBO implements Serializable {
    private static final long serialVersionUID = -36288445272926615L;
    private Long id;
    private String categoryName;
    private Integer categoryType;
    private String imageUrl;
    private Long parentId;
    private Integer count;
}

2.4.1、定义Convert接口

@Mapper
public interface SubjectCategoryDTOConvert {
    SubjectCategoryDTOConvert INSTANCE = Mappers.getMapper(SubjectCategoryDTOConvert.class);
 
    //将DTO转换为BO
    SubjectCategoryBO convertDTOToBO(SubjectCategoryDTO subjectCategoryDTO);
 
    //将List<BO>转换为List<DTO>
    List<SubjectCategoryDTO> convertBoListToDTOList(List<SubjectCategoryBO> subjectCategoryBOList);
 
    //将BO转换为DTO
    SubjectCategoryDTO convertBoToCategoryDTO(SubjectCategoryBO subjectCategoryBO);
}

2.4、性能好的原因

Java程序执行的过程，是由编译器先把java文件编译成class字节码文件，然后由JVM去解释执行class文件。Mapstruct正是在java文件到class这一步帮我们实现了转换方法，即做了预处理，提前编译好文件，如果用过lombok的同学一定能理解其好处，通过查看class文件，可以看出SubjectCategoryDTOConvert 被打上org.mapstruct.Mapper注解后，编译器自动会帮我们生成一个实现类SubjectCategoryDTOConvertImpl，并实现了convertDTOToBO、convertBoListToDTOList、convertBoToCategoryDTO这些方法

从生成的代码可以看出，转化过程非常简单，只使用了UserPo的get方法和UserEntity的set方法，没有复杂的逻辑处理，清晰明了，所以性能很高

 相对于BeanUtils来说

BeanUtils，转换的原理是使用的反射，反射的效率相对来说是低的，因为jvm优化在这种场景下有可能无效，所以在对性能要求很高或者经常被调用的程序中，尽量不要使用。我们平时在研发过程中，也会遵守这个原则，非必要，不反射。


从下面的BeanUtils的copyProperties方法代码中可以看出，转化逻辑非常复杂，有很多的遍历，去获取属性，获取方法，设置方法可访问，然后执行，所以执行效率相对Mapstruct来说，是非常低的。回头看Mapstruct自动生成的实现类，简洁、高效

 BeanUtils的copyProperties方法的源码：

 private static void copyProperties(Object source, Object target, @Nullable Class<?> editable, @Nullable String... ignoreProperties) throws BeansException {
        Assert.notNull(source, "Source must not be null");
        Assert.notNull(target, "Target must not be null");
        Class<?> actualEditable = target.getClass();
        if (editable != null) {
            if (!editable.isInstance(target)) {
                throw new IllegalArgumentException("Target class [" + target.getClass().getName() + "] not assignable to Editable class [" + editable.getName() + "]");
            }
 
            actualEditable = editable;
        }
 
        PropertyDescriptor[] targetPds = getPropertyDescriptors(actualEditable);
        List<String> ignoreList = ignoreProperties != null ? Arrays.asList(ignoreProperties) : null;
        PropertyDescriptor[] var7 = targetPds;
        int var8 = targetPds.length;
 
        for(int var9 = 0; var9 < var8; ++var9) {
            PropertyDescriptor targetPd = var7[var9];
            Method writeMethod = targetPd.getWriteMethod();
            if (writeMethod != null && (ignoreList == null || !ignoreList.contains(targetPd.getName()))) {
                PropertyDescriptor sourcePd = getPropertyDescriptor(source.getClass(), targetPd.getName());
                if (sourcePd != null) {
                    Method readMethod = sourcePd.getReadMethod();
                    if (readMethod != null) {
                        ResolvableType sourceResolvableType = ResolvableType.forMethodReturnType(readMethod);
                        ResolvableType targetResolvableType = ResolvableType.forMethodParameter(writeMethod, 0);
                        if (targetResolvableType.isAssignableFrom(sourceResolvableType)) {
                            try {
                                if (!Modifier.isPublic(readMethod.getDeclaringClass().getModifiers())) {
                                    readMethod.setAccessible(true);
                                }
 
                                Object value = readMethod.invoke(source);
                                if (!Modifier.isPublic(writeMethod.getDeclaringClass().getModifiers())) {
                                    writeMethod.setAccessible(true);
                                }
 
                                writeMethod.invoke(target, value);
                            } catch (Throwable var17) {
                                throw new FatalBeanException("Could not copy property '" + targetPd.getName() + "' from source to target", var17);
                            }
                        }
                    }
                }
            }
        }
 
    }

所以综上所述，

Mapstruct的高性能是毋庸置疑的，这也是我选择使用他的根本原因。在使用方式上和BeanUtils对比，Mapstruct需要创建mapper接口和自定义转换工具类，其实上手成本并不高，但是我们换取了高性能，这是非常值得的，所以强烈推荐大家使用Mapstruct，是时候和BeanUtils说再见了

对于 Mapstruct更深入的学习，大家可以自己自行搜索学习~